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.

[nnattawat]

I agreed with the fact that it is not really a standard way and fetch should not support it. For my case, I kind of need to get it done as an interim solution while 3rd party provider is making a change on their API. So I want to share the solution that I went with using node http module in case someone else is in the same situation as me.

import https from 'https';
import http from 'http';

const requestWithBody = (body, options = {}) => {
    return new Promise((resolve, reject) => {
        const callback = function (response) {
            let str = '';
            response.on('data', function (chunk) {
                str += chunk;
            });
            response.on('end', function () {
                resolve(JSON.parse(str));
            });
        };

        const req = (options.protocol === 'https:' ? https : http).request(options, callback);
        req.on('error', (e) => {
            reject(e);
        });
        req.write(body);
        req.end();
    });
};

// API call in async function
const body = JSON.stringify({ a: 1});
const result = await requestWithBody(body, options = {
        host: 'localhost',
        port: '3000',
        protocol: 'http:', // or 'https:'
        path: '/path',
        method: 'GET',
        headers: {
            'content-type': 'application/json',
            'Content-Length': body.length
        }
    };
)

[redeemefy]

This might bring some clarity. Not that favors one side or the other but at least brings context to the conversation.
elastic/elasticsearch#16024

[SmashingQuasar]

From what I read in this issue and the associated comments, I see that the refusal is based on a theoretical vulnerability. I have put a great deal of thought about this but I fail to see how sending a body with a GET method can create a vulnerability? Could someone clarify this point with a concrete and reproducible example, please?

I also read the RFC again - and the comments on the Elasticsearch issue are pretty clear about that as well - I still fail to see where the RFC forbids to have a body using a GET method. It never states that anywhere from what I read. It only recommend using POST but there is no hard restriction. The RFC tends to be very clear about what is strictly forbidden and this is not the case.

[gibson042]

httpwg/http-core#202 is something of a focal point for this conversation, and was resolved by updating the latest HTTP spec draft in httpwg/http-core@f34f677 to include the explanation you're asking for:

A client SHOULD NOT generate a body in a GET request. A payload received in a GET request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [Messaging]).

It's not so much that HTTP clients are strictly forbidden from including content in a GET request, it's that HTTP servers may not use such content.

[Zamralik]

It's not so much that HTTP clients are strictly forbidden from including content in a GET request, it's that HTTP servers may not use such content.

So basically they're asking for people to bypass the standard completely and only use POST for everything just so they could use clean payloads without obstacles.

[J-Zeitler]

Just a question here, not advocating for any side in the debate :)

I'm a bit confused if this is a restriction in the Fetch specification or in Fetch implementations. If it's a spec thing, could someone point me to the relevant lines in https://fetch.spec.whatwg.org/? Tried to find what methods should support bodies but was unable to.

[Zamralik]

Rather than fix the implementation, they opted to subset the HTTP specification to fit the implementation of fetch().

Rule 33 of "The new Request(...) constructor steps are:" https://fetch.spec.whatwg.org/#dom-request

If either init["body"] exists and is non-null or inputBody is non-null, and request’s method is GET or HEAD, then throw a TypeError.

Which prevents doing clean call with complex nested structures like the fake code below.

const response = await fetch("/endpoint/search-something", {
    method: "GET",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        foo: {
            bar: "qux",
            qux: {
                bar: "foo"
            }
        }
    })
});

If you wanted to make a proper API to handle front & back interactions, you can't.

[einord]

So imagine if the fetch API added this capability to have a body with a GET request. It might not even work on some operating systems anyway, so browsers would be forced to not support it for the sake of consistency.

This is not true, it's the other way around.
If The Fetch API added this capability, browsers and other frameworks would have to start supporting it eventually. Yes, it would be a somewhat painful time at first, but not more painful than it currently is now limiting peoples applications for arbitrary reasons.

[Zamralik]

So imagine if the fetch API added this capability to have a body with a GET request. It might not even work on some operating systems anyway, so browsers would be forced to not support it for the sake of consistency.

This is not true, it's the other way around.
If The Fetch API added this capability, browsers and other frameworks would have to start supporting it eventually. Yes, it would be a somewhat painful time at first, but not more painful than it currently is now limiting peoples applications for arbitrary reasons.

Exact !

What we can be certain of is that browsers, OS, proxies, ... will never bother implementing something that is explicitly forbidden by the standard.

The way it works is :

1. Standard says something is fine
2. It is slowly implemented on some products
3. It's implemented enough that it become used with a polyfill/compatibility wrapper
4. As it is more and more used, it gets implemented on every products
5. It is used raw without a polyfill/compatibility wrapper

Being allowed by the standard is the first step.

The only reverse situation is when you have a step 0)
=> A nice missing feature that is not mentioned in the standard is added to some products

But it will never happen if that feature is forbidden by the standard.

[SmashingQuasar]

Also, the Fetch API (and thus the DOM API overall) is establishing the standard for browsers. It's not up to browsers to determine if they feel like implementing it or not. If they don't, then they will fall behind technologically speaking and will end up like Internet Explorer.
The more I read this discussion, the more it looks like a dogma than an objective approach to this problem.

[cliffordfajardo]

I tried using fetch and node-fetch to make GET with a request body, but it fails with:

Request with GET/HEAD method cannot have body

Workaround for Nodejs runtimes (not in browser ... JS on the server)

Unfortunately the API I'm working with I cannot change at this time so I needed a work around.
You can use the axios library to make GET with request body's

// only works in node / server -- i have not tried in the browser
const res = await axios.get("/api/devices", { 
  data: { deviceName: 'name' } 
}) 

[chrisrollins]

I tried using fetch and node-fetch to make GET with a request body, but it fails with:

Request with GET/HEAD method cannot have body

Workaround for Nodejs runtimes (not in browser ... JS on the server)

Unfortunately the API I'm working with I cannot change at this time so I needed a work around. You can use the axios library to make GET with request body's

// only works in node / server -- i have not tried in the browser
const res = await axios.get("/api/devices", { 
  data: { deviceName: 'name' } 
}) 

It will not work in browser because the available APIs don't allow it.

Also note that on some operating systems it won't work because the underlying HTTP implementation does not allow it. IIRC that includes iOS and Windows.

In theory you could implement an HTTP client from scratch using lower level network APIs and guarantee the ability to have a body in GET requests... But still can't do this in browser because such low level APIs are not available.