CFHTTP doesn't send username and password attributes as Basic Authentication header over SSL


Specifying username and password attributes in cfhttp should result in a Basic Authorization header being sent (using the default authType and preAuth attribute values).

When the URL is standard http over port 80, this happens, but with an SSL URL over 443 the Authorization header is not automatically sent.

ACF sends the Auth header regardless of SSL.

Steps to reproduce

1. Make a .cfm file containing <cfdump var="#GetHttpRequestData()#"> available at an HTTPS URL.
2. Call the URL over HTTPS using

3. Check for an "Authorization" header in the output.


Sending the Authorization header manually in Lucee using cfhttpparam works:

Previously raised against Railo




Igal Sapir
April 25, 2018, 3:52 PM

I don't believe that the Java Runtime version is a factor in this case.

When I compare your debug output to mine, I see that the Authorization headers are sent in the https request only in the "challenge" phase, after the server sends back the WWW-Authenticate header

Can you test it on a URI that requires Basic Authentication?

Do you know if ColdFusion uses the Apache Http Client library? If so, what version? That is more likely to be a factor here.

The only "solution" that I can think of at this point is to "convert" the username/password to a regular header, but personally I am against that because it has a bigger potential of breaking something else.

Igal Sapir
April 25, 2018, 4:04 PM

I will try the solution documented at and see if it helps.

According to that article the header is sent only when challenged by default, as I have discovered earlier.

Igal Sapir
May 27, 2018, 9:05 PM

OK, I found the source of the issue.

Apparently this is the behavior of the HttpClientBuilder by design, as documented at under section 4.6. Preemptive authentication, which reads:

HttpClient does not support preemptive authentication out of the box, because if misused or used incorrectly the preemptive authentication can lead to significant security issues, such as sending user credentials in clear text to an unauthorized third party. Therefore, users are expected to evaluate potential benefits of preemptive authentication versus security risks in the context of their specific application environment.

It doesn't explain why we see it in the non https version, but at least now that we understand what's going on we can address it.

Igal Sapir
May 28, 2018, 3:27 PM

Thank you, for the information and for providing the test server.

Julian Halliwell
May 28, 2018, 4:43 PM

Thanks for persisting and getting to the bottom of this.



Igal Sapir


Julian Halliwell




Fix versions



Affects versions