I don't think the handling of 101 responses is the problem; we'd encounter the same issue if the server had sent a 102 instead. The issue is that we're trying to process a DATA frame (or what looks like one) before the final headers have been read., which causes an internal panic. The panic is then obscured by a deferred cleanup function that gets stuck waiting on a mutex that was locked when the panic happened.
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
Darwin / ARM64 / AMD64, but also reproduced on Linux / AMD64.
What did you do?
Run the following code with server that completes TLS handshake, but then just sends random raw data.
In other words, our client never receives frame with
What did you expect to see?
After 3 seconds, the connection is aborted.
What did you see instead?
The connection hangs indefinitely.
We've seen this happen with Cloudflare in front of a non-http(s) backend.
In this case we assume it is wrongly configured to point at a SSH daemon.
Even in that case, we should not hang forever.
x/net/http2 also provides a
PingTimeout. According to the docs:
So the following was tried:
This still hangs indefinitely.
The text was updated successfully, but these errors were encountered: