Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: support GET-with-body in Transport/Server #13722
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:
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.
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
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
Another point of reference:
referenced this issue
Jun 29, 2016
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.