-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
caddy 2.5.1 + experimental_http3 + fastcgi reverse_proxy always returns 500 #4819
Comments
Are you able to use wireshark or similar to watch the traffic? I think the 500 status message must be coming from the upstream, it might not be happy with something in the request before it reaches your handler. |
@francislavoie thanks will try this and post the results. |
I was not able to find a way to sniff packets for the unix socket. So I changed the go-fastcgi app to listen on tcp port 9000, and I changed my Caddyfile to:
With this I was able to recreate the http3 500 errors, and http2 worked as expected. Here is some data from Wireshark showing responses from go-fastcgi to caddy when using http/3: So it looks like my go-fastcgi app is hitting this: https://github.com/golang/go/blob/master/src/net/http/cgi/child.go#L62
From caddy debug logs - I have seen in outgoing fastcgi requests when using http3 in caddy:
and when using http2 in caddy I see this in outgoing fastcgi requests:
So finally I think the issue is go's See this go playground for a small demo: https://go.dev/play/p/HgK2fi1r8Bb I think this is probably a bug in caddy in that |
Further observations:
|
Interesting. Thanks for investigating! FYI @marten-seemann, I think quic-go should report |
Thanks for the deep investigation! Sounds like a likely easy fix. |
What makes you think that it should be HTTP/3.0? The name of the protocol is HTTP/3 (compare to HTTP/2, which specifies HTTP/2.0 preface here: https://datatracker.ietf.org/doc/html/rfc7540#section-3.5). |
My use case is:
With out-of-the-box HTTP/2 in caddy everything works as expected. I tried turning on After some debugging above - I am finding:
A couple of thoughts on how to fix this:
Thanks! |
The HTTP/3 doesn't specify a serialization of the HTTP version, as far as I can see: https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-4.1.1.1. So it seems like the value we set on the @aaronriekenberg Do you agree with that reading? If so, do you want to send a PR in quic-go? |
Created a PR for quic-go: quic-go/quic-go#3439 Thank you! |
facing the same problem with reverse_proxy, here's the clue v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=
(http://127.0.01:3000 is also serving with caddy2 as encode zstd gzip.) when got 500 failed, it reports following error
updated: |
@mindon I'm pretty sure that's not the same problem as was described in this issue either. This issue was specific to HTTP/3, and did not involve That said, we can close this soon, once we bump the quic-go dependency to v0.28.0 (FYI @mholt if you want to do that just before our next release https://github.com/lucas-clemente/quic-go/releases/tag/v0.28.0) |
Validated my original use case works in caddy 2.5.2 Thanks all! 😄 |
Running caddy on a 64-bit install of raspberry pi os lite.
Have a small go app acting as a fastcgi server listening on a unix socket. This app is using the standard
"net/http/fcgi"
package in go 1.18.2: https://github.com/aaronriekenberg/go-fastcgicaddy is acting as a file server and reverse proxy to the go fastcgi app.
Things work perfectly with the default HTTP/2 in caddy.
But as soon as I enable
experimental_http3
in my Caddyfile I observe:experimental_http3
experimental_http3
and I see in chrome dev tools the requests are using http3. So the issue seems isolated toexperimental_http3
+ fastcgi reverse_proxy.My Caddyfile:
Debug errors in caddy log when making a request using http3:
The text was updated successfully, but these errors were encountered: