HEAD requests may have a body, although RFC 7231 states that "some existing implementations" may reject a HEAD request which contains one.
The net/http package handles HEAD requests with a body in different ways:
HTTP/1, non-chunked: return a 400 error, close the connection.
HTTP/1, Content-Encoding: chunked: ignore the chunked body (trying to parse it as the next request on the connection). Clearly buggy. Not a request smuggling mechanism, since the chunked body data can never be a valid HTTP request.
HTTP/2: close the stream with an error.
We should either support HEAD requests with a body in all circumstances, or fix the HTTP/1 chunked case and add a test for the HTTP/1 identity case. I think support, but I could be argued into always-reject on the grounds that nobody ever actually sends a body in a HEAD request.
Thanks to Bahruz Jabiyev, Tommaso Innocenti, Anthony Gavazzi, Steven Sprecher, and Kaan Onarlioglu for reporting this issue.
The text was updated successfully, but these errors were encountered:
The semantics of HEAD requests with a body are undefined--there's no RFC that I know of that defines what that body means--but the mechanics of sending such a request are well-defined. HEAD responses are defined as having no body, but HEAD requests may have one.
The argument I see against supporting HEAD requests with a body is that nobody sends these in practice, so receiving one probably indicates a mistake or malicious behavior of some kind.
The argument for supporting them is that they're valid requests, and that it's more work to reject them than it is to just handle them.
The actual state of support for HEAD-with-a-body in net/http is a bit of a mess as described above, so we need to do something. (The one case I forgot to mention is client behavior: net/http handles sending HEAD-with-a-body fine in all cases I've tested, including HTTP/1, HTTP/2, identity encoding, and chunked encoding.)