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

More and more, applications are built as thick clients sending complex queries to a thin server (see [this](http://tonsky.me/blog/the-web-after-tomorrow/)). Many of queries are requests for data, and are free from side effects. A few projects that do this (ie. support arbitrarily large browser queries to retrieve data) include:

- ElasticSearch (query API uses [GET with body](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html))
- Facebook's GraphQL (query syntax is a [nested JSON structure](https://github.com/facebook/graphql#query-syntax))
- Netflix's Falcor (query syntax is a [JSON structure](https://youtu.be/hOE6nVVr14c?t=2295))
- Meteor's DDP (queries support [EJSON params](https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md#messages-3))

RFC 7231 allows GET bodies ([spec](https://tools.ietf.org/html/rfc7231#section-4.3.1)), but Chromium's XMLHttpRequest implementation does not ([source](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp&l=871)). This prevents us from GETting data that requires an arbitrarily large query to fetch.

There are work arounds, each with its own drawbacks:

- Use a POST (semantically incorrect, imposes restrictions on browser-level caching)
- Use a custom HTTP method (doesn't play well with application/network middleware)
- Use websockets with a custom subprotocol (difficult to implement in a RESTful way)

It seems to me that the best, most backward-compatible solution is to permit bodies for GET requests with the fetch API.

What does everyone think?

(This is continuing the discussion I had with @albertywu, @pathikrit, and @igrigorik)

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