http://coldfusion.com logo
Join Slack
Powered by
cfhttp.filecontent: `Connection Failure` always ba...
# cfml-general
d
cfhttp.filecontent: 
Connection Failure
always baffles me. I'm never sure what it means.
cfhttp itself doesn't error out.
a
I presume you also got a status code like a 502 / 503. The server servicing the request can't connect to some other service it needs to fulfil your request
It's not indicative of your code erroring. It's their code.
d
I'm checking the log to see what the status code is on those requests ...
a
just... erm... look @ 
cfhttp.status_code
or whatever it is.
b
@Daniel Mejia If there is a connection failure, that means there ISN'T a response code
If I call you and you don't pick up the phone, it's impossible for you to tell me anything.
d
right, but since I am already logging it... Anyways, 
Status code unavailable
a
Oh OK so one gets just 
connection failure
in the response body... if the upstream server doesn't respond @ all?
b
Right, that means the TCP connection was never even made, let alone an HTTP request/headers sent, let alone an HTTP response returned
If you were hoping for an exception to be raised, try adding 
throwonerror=true
to your cfhttp tag.
a
that should be the default though, yeah?
b
not according to CFDocs
But I haven't tested if Lucee and Adobe agree on that
a
I'm looking at Adobe's docs. Don't care what third parties say šŸ˜‰
b
d
So tcp connection failed. how do I know what party is fault here?
a
OK, so bug in Lucee and bug in cfdocs. Or maybe bug in Adobe's docs šŸ˜‰
As long as there's a bug in something, I'm happy
b
how do I know what party is fault here?
You don't really, it's sort of like a letter coming back as 'undelivered'. The connection could have broken down at any point in the internet starting with your severs's network adapter
d
holy shit
wow that sucks
a
tracert the host?
from the CFML server
b
Yes, testing a ping/tracert would be a great start
d
well. here is the curve ball: almost every other cfhttp call fails.
t
you on cf2021?
d
you on cf2021?
acf 2018
t
my favorite cf2021 bug is the one where when you're using an encrypted database connection, it makes all http traffic puke and die. But you appear to be lucky, and that's not it.
d
Puzzling that some calls are ok and some fail.
If I spin up a nodejs server and try these requests, I assume I will get similar tcp connection results. Right?
t
eh, maybe. If you do, that's informative.
If you don't, then it's probably a java related issue.
using a certificate that's not recognized by the jvm or something.
d
so is it possible the ssl cert for 
<https://service4.ultipro.com>
is not secure enough or expired??
a
Bug in Lucee docs & cfdocs. The default is "false" on both CF and Lucee.
b
I've never seen cert errors be intermittent. Start with the ping and work from there
a
@Daniel Mejia did you actually look at the rest of the response object from the http req?
Cos like...

https://i2.paste.pics/19d96e9726d094b0b7e7a8de03c6082b.pngā–¾

I get a 302 from the browser, that said.
Copy code
adam@DESKTOP-QV1A45U:~$ curl -v <https://service4.ultipro.com>
*   Trying 208.86.169.145:443...
* TCP_NODELAY set
* Connected to <http://service4.ultipro.com|service4.ultipro.com> (208.86.169.145) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=Florida; L=Weston; O=The Ultimate Software Group, Inc; CN=*.<http://ultipro.com|ultipro.com>
*  start date: Dec 27 00:00:00 2021 GMT
*  expire date: Jan  3 23:59:59 2023 GMT
*  subjectAltName: host "<http://service4.ultipro.com|service4.ultipro.com>" matched cert's "*.<http://ultipro.com|ultipro.com>"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: <http://service4.ultipro.com|service4.ultipro.com>
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: <https://connect.ultipro.com/documentation#/api>
< Date: Tue, 02 Aug 2022 21:56:26 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host <http://service4.ultipro.com|service4.ultipro.com> left intact
d
What does that mean Adam?
Check this. the errordetail is: 
I/O Exception: Remote host terminated the handshake
a
That is what is happening for me when I curl that URL you mentioned before. So it's up and responding. All the TLS stuff is a bit beyond me, but... problem is between you and them. Not with them.
b
Remote host terminated the handshake
That usually happens when an SSL connection can't agree on what ciphers or TLS version to use
Which is largely controlled by your version of Java.
a
So perhaps curl is a bit more aggressive at trying than CF is?
b
If you use a packet sniffer to watch the SLL negotiation, you may be able to find out, but I've never done that. I've researched this from the server side of things. I suppose adding in the SSL JVM debugging args would probably tell you more, but the signal to noise ratio of those logs is just atrocious
Something like
Copy code
-Djavax.net.debug=ssl:handshake:verbose
d
what log file does that write to?
b
console
or more specifically, your servlet's standard out log.
d
in a traditional acf install where is that?
b
The coldfusion-out log in the cf logs folder
s
I see 
http://
in all that output -- are you making 
http
requests or 
https
requests? Is that service expecting 
https
these days? A lot of services have been tightening up what type of connection they require and no longer allowing older, less secure connections even via 
https
. When I try the connection Adam tried with 
http:
, it redirects to 
https:
(sort of as I would expect these days). When I try it with 
https:
, I get the same output as Adam (ending in a redirect to the API documentation) but I would call out the negotiated SSL:
Copy code
SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
ā€¢ I have no idea what various versions of ACF support and I don't when JDK you're using. Both of those could factor into that. You say some calls succeed and some fail -- from the same ACF server? With similar URLs? Or is there some pattern to what fails and what succeeds. You'll need to dig deep into debugging this, probably by logging all requests (full URL) and seeing which ones fail and which ones succeed.
y
For me most of the time it was SSL certificate issue. We need to install it on ColdFusion side.
m
I was dealing with this issue all week! Our server was trying to talk to another server on campus and it returned "Connection Failure". I knew it wasn't the code. In the end, the other server had their default gateway incorrectly entered on ipv4, but their ipv6 was fine. Our server was only talking on ipv4. So my desktop computer could access it just fine (configured for ipv4 and ipv6). Just the server was having the issue.
5 Views
Open in Slack
PreviousNext
Powered by