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.
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 4.2.1.008 https://issues.jboss.org/browse/RAILO-3315
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.
I will try the solution documented at http://www.baeldung.com/httpclient-4-basic-authentication and see if it helps.
According to that article the header is sent only when challenged by default, as I have discovered earlier.
OK, I found the source of the issue.
Apparently this is the behavior of the HttpClientBuilder by design, as documented at http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html 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.
Thank you, for the information and for providing the test server.
Thanks for persisting and getting to the bottom of this.