Re: [fetch] Proposal: Support GET bodies (#83)

To give some context - RFC7230 allows *all* request methods to have bodies, because we want generic parsers; they shouldn't have to have knowledge of a specific method's semantics to parse a message.

The relevant text in 7231:

> A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

... and indeed this is the case; most HTTP APIs (client and server side) don't provide access to GET bodies, and many firewalls, etc. will block requests with them. It's also not uncommon for GET bodies to outright cause bugs, because most software doesn't expect them.

So, HTTP doesn't "allow" GETs to have bodies in the sense that it's recommending it as a good practice; it's just an artefact of how HTTP parsing is specified.

We're having a discussion of this issue in HTTP WG now; semantic Web folks want to be able to perform complex queries as well, and the current proposal is to use a new method. See:
  http://tools.ietf.org/html/draft-snell-search-method
That isn't going forward yet, because there isn't a compelling argument against just using POST.

Besides that, note that there is no defined maximum length on URIs in HTTP; 7230 says:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

http://httpwg.github.io/specs/rfc7230.html#request.line

I.e., this could equally be addressed in fetch by requiring support for longer URLs.

Also, AFAICT, the only one of the links above actually using a body in a HTTP GET is the first one, which says:

> Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/83#issuecomment-155946059