Request with GET/HEAD method cannot have body.

[chrisrollins]

I ran into this restriction while building HTTP functions for a library. I think this should be reconsidered because sometimes people actually use the body in a GET request. Notably, ElasticSearch can use it for queries. It can use the querystring instead, but that can be pretty cumbersome which is why it also accepts a body for GET queries.
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html

Since I'm making a library I want to allow everything within the specification of HTTP but apparently fetch has its own rules, and as you can see it's possible for that to interfere with using an API._

You'd think this is an edge case, but if it interferes with something like ElasticSearch maybe it's not an edge case._

[mnot]

HTTP allows a request body on GETs syntactically so that message parsing is generic; it doesn't say that a body has any meaning on a GET.

So, anyone using a body on a GET is effectively "off the reservation"; they're not longer using HTTP, but defining their own private protocol. Since Fetch is an API for HTTP, it's entirely reasonable for it not to allow this.

More practically, using bodies on GETs tends to trigger interop problems with proxies, CDNs, servers, etc. While it might work in the lab or even on the Internet under controlled conditions, using it at scale is very likely to bump into this. For example, users who have virus scanning proxies are likely to have problems, since they tend to have very conservative implementations.

[chrisrollins]

Mark, thanks for your response.

This isn't about me or any individual wanting to use a body on a GET. It's about the fact that it is used in industry which you can see in the ElasticSearch documentation which I linked in my first post. ElasticSearch is used at scale in industry. Don't try to convince me not to use it. Convince people like Elastic company not to use it.

My point is, I don't think additional rules should be added to a spec even in parts where the spec isn't explicitly clear, especially when it can be shown that it limits certain industry applications.

[mnot]

If we changed how we use HTTP (or TCP, or any other protocol) to accommodate every abuse in "industry" like this, we'd quickly lose all of the value of having a shared protocol. Get them to fix their software, don't try to convince everyone else to accommodate their non-standard use.

[annevk]

Duplicate of #83. As far as I know nothing changed since then.

[laddi]

every abuse in "industry" like this

Doing something that is allowed within the HTTP spec is hardly abuse. It seems odd that the creators of this get to dictate how APIs should and should not work...

don't try to convince everyone else to accommodate their non-standard use

Well, you should take your own words to heart because what people are trying to accomplish is definitely according to standard...

[SmashingQuasar]

So far I could reference the following arguments against the addition (in fact it is a suppression) of this:

• Semantics hardly matters and changing the way things work takes time: This is the point of a standard, being semantically correct and accurate. Everything takes time in our jobs. In my opinion this argument is totally invalid.
• This can cause security issues because the body is sent silently (+ all other security concerns): This is a legit point to postpone the suppression of this but not to reject it all together. There is nothing impossible to fix about those security problems.
• Some server (exaggerated originally as "most servers", which is wrong) do not support this: This shouldn't be a concern. If a server does not support this then most likely you can expect many other issues with this. It is most likely a server that just does not follow the RFC and does its own thing. A standard should not care about this use case.
• There are alternatives like the POST method: Which is semantically incorrect thus shouldn't be promoted by a standard. The SEARCH method is definitely promising but I couldn't find any evidence supporting that will be implemented whatsoever. I would gladly be proven wrong on this last sentence since it would be a good addition that would probably solves this debate.

Please consider that all people that wrote messages about this concern aren't trolling or trying to enforce a point of view. Sending a GET Request with a body is used widely in the industry and is not explicitly forbidden by the RFC. Refusing to allow it for the reasons that I listed is just being conservative and reactionary. It does not promote progress in the slightest.

[rwlaschin]

Elasticsearch rest api requires sending a body with a GET. Please at least provide an option for disabling this. Sending a body with GET is part of the standard.

[Zamralik]

If some specific platforms/frameworks reject handling GET/HEAD requests with a body, those who use them will work around by making bodyless GET/HEAD requests or switching to standard compliant platforms/frameworks.

There are already platforms/frameworks handling GET/HEAD requests with a body, some of them also handle security and caching.

It isn't right to enforce non-standard behavior on the fetch API.
It forces the use/implementation of workarounds/hacks/middlewares to be standard compliant.

[annevk]

I recommend reading #83 for some background as to why this is not that simple. But really, if you can convince browsers to add this and overcome the hurdles discussed there, it'd happen. Advocacy here is unlikely to help with that though.

[annevk]

(Also, SEARCH works perfectly fine with fetch() in all browsers. You can even use CHICKEN as method if you want.)

[Zamralik]

@annevk
I had already read #83 before my previous answer.

Using a non-standard HTTP method is not an acceptable solution to a non-standard HTTP behavior.
Using non-standard HTTP methods go against the security/caching handling based on HTTP method.

Browsers follows the Fetch API standard, and suggesting otherwise is a bad call.
Browsers shouldn't be encouraged to not follow standards.
Noone wants to go back to the era when websites were made for specific browsers.

There is a HTTP standard. There is Fetch API standard.
Browsers should be compliant with the Fetch API standard.

Fetch API works using HTTP, so it should be compliant with HTTP standard unless it cause a security breach.
Security verification disallowing GET requests to have a body is not a concern for the standard.
There's no security imperative as GET requests are safe by nature (no modification).
If there's a security breach caused by a GET request, it's an implementation issue on the server, and should not be a concern for the standard as bad server implementations can exists for everything.

[chrisrollins]

I recommend reading #83 for some background as to why this is not that simple. But really, if you can convince browsers to add this and overcome the hurdles discussed there, it'd happen. Advocacy here is unlikely to help with that though.

Can you be more specific about this? Which unique considerations are there for the browser application that makes it so difficult to allow this in the Fetch standard? I mean, keep in mind that if somebody really wants to send a GET with a body, they can do it with any other application. The issue with that is many developers want to implement internal tools as browser apps because it is convenient and safe.

[annevk]

It's as simple as allowing new things to be send to unsuspecting servers. Non-browser applications might not necessarily have the same state or run on the user's computer and therefore have access to the user's private network.

The bigger problem is lack of implementer interest though, as noted above.