errordetail string Unknown host: metadata.google.internal
filecontent string Connection Failure
header string
mimetype string Unable to determine MIME type of file.
responseheader Struct
status_code number 0
status_text string Connection Failure
statuscode string Connection Failure. Status code unavailable.
text boolean true
It seems that Google is doing a redirect in someway that CFHTTP simply cannot handle, but curl can.
I’ve played with the redirect parameter to cfhttp to no effect.
Anyone else experience anything like this? I’ve been prodding at this issue for the last couple of days and I’m not having any luck.
Version Lucee 5.3.10.97
Version Name Gelert
Release date Nov 25, 2022
Remote IP 172.17.0.1
Servlet Container Apache Tomcat/9.0.75
Java 11.0.19 (Eclipse Adoptium) 64bit
Host Name localhost
OS Linux (6.1.0-9-amd64) 64bit
Architecture 64bit
Inspect Templates (CFM/CFC) Never ( Best Performance )
Key case Convert to upper case (CFML Default)
Null Support Complete Support
Local scope mode Classic (CFML Default)
I’m running inside a docker container on my Debian 12 desktop. And my curl test is run inside this container as well.
Hmm - running thru a proxy? Can you point to a bit more info?
I also should run this in it’s eventual environment (GCP Cloud Run) it shouldn’t have issues finding metadata.google.internal there.
But since curl resolves this just fine in my test environment, it seems that cfhttp should be able to as well. (although, I realize I’m pretty deep into the weeds with this sitch).
Maybe I need to learn more about what a proxy actually is. I think you’re suggesting set up some kind of proxy inside Cloud Run (where ‘internal’ would be resolved) then add that proxy to the cfhttp request. That’s one approach to get this operating on my desktop but I’m going to see if it’ll run correctly inside Cloud Run first.
But still wondering why curl works just fine from this container (running locally) while cfhttp simply cannot.
In particular, in this case, please indicate the Java version that lucee is using. I suspect your problem is not with Lucee (or cfhttp) but with the underlying Java it runs on. As you may know, cfhttp gets converted into a Java httpclient call. Curl is not java-based. In most cases of such failures, the crux is in the url using https (which I realize you likely can’t change).
Sometimes such https failures are due to certificate issues, having to do with certs implemented within Java, or not. In this case (of such a public url), I doubt that’s it.
The next most common issue is if the tls/SSL versions supported by the server you’re calling differs from what your java version supports. Perhaps you’re on an older Java, and the server you’re calling wants to use newer tls algorithms than the old Java supports. Or it could also be the reverse: since Apr 2021, jvm updates no longer support such https calls to servers that don’t support at least tls 1.2.
These are just guesses, but from experience helping people with such problems. I have blog posts on each:
And if somehow this or thoughts from others here don’t end up helping you resolve thing on your own, I’ll note that I help people solve such problems daily, via remote consulting, often in well less than an hour. You won’t pay for time you don’t find valuable. More at Charlie Arehart's Server Troubleshooting Consulting Services.
Fwiw, I was writing my last post in reply to cfmitrah’s first comment (asking for details), and the few replies in between came while I was writing. Oddly, the site didn’t let me know there were new posts (I thought it did offer such notifications while replying, or I’d have checked first and revised my comment a bit, considering those). I’ll always check, from now on, and just did.
In any case, I hope it may help Brian or others facing similar challenges.
Oh - Thanks Zackster. More to play with . . . tho, I’ll note that I cannot pingmetadata.google.internal from a shell in the container. So, I don’t think it’s an address resolution issue. Somehow, curl handles whatever is needed. I may try corretto vs openjdk? Or maybe it’s about SSL as one of Charlie’s notes suggests?
I’ll be digging around today and report back here.
@Zackster I think you may know best whether it’s worth playing with higher versions of java (and /or tomcat). I guess I am on the latest version of 11, but dockerhub shows tomcat 9 with jdk17 and jdk21. At the moment - I’m just assuming I should avoid versions above 11 as ‘not ready’. Sound right to you?
No - that internal domain really is invisible to me. So, I’m not sure what’s happening but it seems like some quality of the connection that curl makes allows ‘iamcredentials.googleapis.com’ to resolve internal connections without an explicit client redirect but the connection java is making requires some kind of client redirect. And the redirect is to a domain that is not resolvable outside GCP. At least, that’s my current theory.
Status (for future visitors):
I was in error - the message that cfhttp gets is a 404 error. (the ‘unknown host’ error was a failed connect attempt elsewhere in the script). The actual error from cfhttp is
errordetail string 404 Not Found
filecontent string
header string HTTP/1.1 404 Not Found Content-Type: text/html Date: Wed, 14 Jun 2023 17:22:10 GMT Server: scaffolding on HTTPServer2 Content-Length: 0 X-XSS-Protection: 0 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
http_version string HTTP/1.1
mimetype string text/html
But the URL that is NOT FOUND is easily found by curl.
My new theory is that somehow Java is munging the URL such that the domain is hit but the path is messed up. I note that the URL has an @ and also ends with a parameter delineated by a colon (:).
Tho URL encoding those characters does not result in a change in behavior.
