You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like this may be an HTTP/2 spec violation according to RFC 9113:
A request or response that includes message content can include a content-length header field. A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the content, unless the message is defined as having no content. For example, 204 or 304 responses contain no content, as does the response to a HEAD request. A response that is defined to have no content, as described in Section 6.4.1 of [HTTP], MAY have a non-zero content-length header field, even though no content is included in DATA frames.
I would expect that the HTTPS server continue waiting for the rest of the request or recognize after some timeout that the request is malformed due to failing this condition:
the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the content
I would not expect the server to return with a 200-level response.
The text was updated successfully, but these errors were encountered:
slizco
changed the title
x/net/http2: Request is not treated as malformed when Content-Length is nonzero and no body is sent
x/net/http2: Request is not treated as malformed when Content-Length is non-zero and no body is sent
Mar 6, 2025
Go version
go version go1.23.3 darwin/amd64
Output of
go env
in your module/workspace:What did you do?
openssl req -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -days 365 -nodes -subj '/CN=localhost'
go run server.go
What did you see happen?
Content-Length
and no body. This hangs indefinitely, with the server waiting for the 10-byte request body:Content-Length
and no body. This returns immediately with successful response:What did you expect to see?
It seems like this may be an HTTP/2 spec violation according to RFC 9113:
I would expect that the HTTPS server continue waiting for the rest of the request or recognize after some timeout that the request is malformed due to failing this condition:
I would not expect the server to return with a
200
-level response.The text was updated successfully, but these errors were encountered: