http://coldfusion.com logo
Join Slack
Powered by
Does anyone know if any changes should be made in ...
# lucee
d
Does anyone know if any changes should be made in order for cfhttp to work with http/2. I have just upgraded to a newer AWS EC2 instance and I am using http/2 rather than http1.1 and all of the sites are working correctly when browsing via a web browser but I have a scheduled task running that makes a cfhttp call that is no longer working.
Copy code
<cfscript>
   cfhttp( url="<https://jobs.isc.co.uk>", method="get", result="result" ) {}
dump(result);
</cfscript>
returns an error: Connection Failure: Unknown host: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty. Any ideas? Running on Lucee 5.4.0.74-SNAPSHOT with 11.0.19 Eclipse Adoptium 64-bit. The SSL is attached to the Load Balancer (which hasn’t changed) - I created a new target group and attached the new EC2 and gradually updated the rules to forward traffic to the new EC2 target group.
b
@davla I don't think cfhttp will work with http/2 since that semantic doesn't really make sense there.
The server should just fall back to http/1
Your error is an SSL error
"trust anchors empty" normally means your trust store is missing or empty
Check your 
cacerts
file and see if it got wiped out. trycf.com has this issue from time to time.
d
Where do I find the cacerts file? Am I looking on the server that is making the cfhttp call or the server where the website I am trying to call?
b
The client (server making the call)
Lucee has its own file under the server context in a security folder
Trust anchors empty means Lucee can't confirm that the remote server cert is signed by someone it trusts because it trusts no one!
d
Is there a doc to show me how to recreate it?
b
You can just copy the one from your jre's security folder
But confirm if it's empty or missing first
Copy code
lucee-server\context\security\cacerts
the location of the server context depends on how you've installed Lucee/
In CommandBox, it's in the 
web-inf
folder in the server home dir.
My cacerts file is around 108 KB
And you can use openssl or a tool like Portecle to inspect it
d
Standard installation. Thanks, will take a look and see where it’s gone awry!
OK, cacerts file is 108kb but I can’t seem to open with openssl - not sure what command args to use.
z
I updated all the bundled cacerts recently https://luceeserver.atlassian.net/browse/LDEV-4497
d
@zackster will updating Lucee to latest snapshot (via Lucee admin) pick up the new cacerts file?
z
ah that's complicated with 5.4, 6.0 uses the jvm one by default https://luceeserver.atlassian.net/browse/LDEV-3986
d
Just updated the jre and that seems to have fixed the problem!
Actually the task is still not running correctly.
Do I copy the cacerts file from the jre and replace the one installed in lucee-server/context/security?
z
yep
d
OK, the cacerts is a red herring. This is the error I am actually seeing from the cfhttp call: HTTP 464 The load balancer received an incoming request protocol that is incompatible with the version config of the target group protocol. Possible causes: • The request protocol is an HTTP/1.1, while the target group protocol version is a gRPC or HTTP/2. • The request protocol is a gRPC, while the target group protocol version is an HTTP/1.1. • The request protocol is an HTTP/2 and the request is not POST, while target group protocol version is a gRPC.
Is there a way to get cfhttp to use http/2 gRPC or do I need to downgrade the load balancer to http/1.1?
z
downgrade
d
I wouldn't think you need to downgrade, but just allow HTTP/1.1 traffic. You should be able to use both.
z
d
@dswitzer Seems like http/2 is an all or nothing option.
Looks like it’s in the Target group config.
Need to create a new target group and point the LB to the new http1 target group - hey ho!
I’ll just stop the cfhttp task for the time being as the it was only checking if the sites had any issues.
b
I always thought HTTP/2 was a graceful downgrade sort of thing
z
like me after 7 pints
b
For example, when I enable HTTP/2 in a CommandBox server, if the browser doesn't support it, they client and server will just negotiate http/1 instead
What's that screenshot from above?
d
I’m deffo not graceful after 7 pints! I switched to a different target group with HTTP/1 and the cfhttp is now working again. Screenshot is part of the AWS Load Balancer config. There are 2 places where http/1 and http/2 are mentioned. Once in the target group setup and then in the Load Balancer config.
The setup is Client --->(port 443) AWS Load Balancer (with SSL cert) --->EC2 target group --->(port 80) EC2 instance(s).
b
I'm failing to see how CFHTTP is actually a part of the issue.
In my experience a proxy can re-send the request to its backend targets using any protocol it wants, irrespective of the protocol that the incoming request used.
d
Me too. But changing the target group (EC2) from an http/2 to http/1 config allows the cfhttp request to function.
b
Right, but is does the issue only happen when the client is cfhttp, or does it happen when using a browser as well?
It sounds like one of your internal proxy hops was forcing HTTP/2 traffic to an endpoint which could not receive that, which would be an issuer regardless of what the starting http client was upstream.
d
No, all browsers are fine. All websites were running fine and accessible from any browser. The cfhttp call was the only failure.
b
What if you hit it over HTTP In a browser?
(HTTP/2 normally only works over SSL)
The issue may have just been any client sending an HTTP/1 request and Browsers tended to use HTTP/2 and cfhttp happened to use http/1
d
http is redirected to https via the load balancer.
b
I would guess perhaps the AWS LB proxies incoming HTTP requests to the backend re-using the same HTTP protocol
So, if you used a browser that didn't support http/2, I would suspect you'd see the same thing there
d
I wonder if it’s something AWS specific. Not to worry now as I have switched the Target group to a http/1 so everything is working as it should. @zackster has created a ticket to upgrade cfhttp to support http/2.
Open in Slack
PreviousNext
Powered by