net/http: support GET-with-body in Transport/Server

[bradfitz]

RFC 2616 is super vague about whether a GET request with a body is valid, or what to do about it.

We should decide, document, enforce, and test.

I vote reject them.

RFC 2616 says:

The rules for when a message-body is allowed in a message differ for
requests and responses.

The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.

But the nothing (even in 5.1.1) about which methods have defined semantics for a body. At least GET and HEAD are not explicitly defined, so maybe that means reject them.

I recall somebody (from CloudFlare?) telling me they'd seen GET+body in the wild, though?

I still vote to reject them.

[odeke-em]

I think I've seen usages of GET+body with ElasticSearch before. In fact just opening the ElasticSearch docs https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html shows

[bradfitz]

Thanks for that reference. That's interesting. Then perhaps we should make sure it's permitted.

[kostya-sh]

I don't know what is the current behaviour but if body is permitted for GET then it should be permitted for DELETE as well: https://www.elastic.co/guide/en/elasticsearch/plugins/2.0/delete-by-query-usage.html

[bits01]

Another point of reference:
https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962

[bradfitz]

Recent discussion on ietf-http-wg mailing list: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0243.html

I'm thinking we should probably make the Server reject GETs with bodies by default unless the server (or the handler) explicitly wants them, either via configuration on the server (some new bool knob?) or implicitly if the handler reads from the body, then we permit a response (similar to how we do automatic 100-continue responses on the first read of the request body).

On the client side, we can probably make it work on the transport by default if the user includes a body. But it would disable auto-retry, as if it were a POST.