[franky47]

While you *can* do the same with a GET (include data in the body), it's not spec-compliant for servers to parse and interpret this data.

https://stackoverflow.com/questions/978061/http-get-with-req...

When designing an API, and if spec compliance is not key, I wonder if client-compliance would become the issue (clients refusing to emit a GET body).

[BugsJustFindMe]

> it's not spec-compliant for servers to parse and interpret this data.

That's wrong. A lot of people just don't understand the difference between SHOULD and MUST when reading standards. The standard just says that you shouldn't rely on servers accepting it unless they tell you.

[mgaunard]

Parsing the body of GET can be added as an extension, same as adding this new QUERY method.

[DaiPlusPlus]

Many “WAF” (Web-Application Firewalls) and reverse-proxies are configured to block “unusual” traffic though, including GET-with-body - but I feel that this approach is like how (around 2000-2006) everyone switched from high-performance or legacy binary protocols to XML/SOAP-over-HTTPS to avoid corporate firewall headaches.

[thwarted]

There will most likely be problems with such web-application firewalls anyway, since those same firewalls will probably reject HTTP methods that they don't know about.

But adding a new new method is probably overall better and matches people's understanding of the implementation and interpretation of GET, even if (with extensions) GET can have a body people don't think of it like that. So a new method with defined semantics and interpretation avoids a whole bunch of sideshow debate about if GET with a body is possible or appropriate.

[mgaunard]

It's not up to debate, GET does allow a body.

[thwarted]

You can make all noise you want about how it's not up for debate because of what the standard says, and said noise does not avoid sideshow bs debates about the how it is used and restricted/limited in practice. A new method avoids that because a new method comes with exactly zero historical baggage.

[mgaunard]

A new method does not give any advantage over extending an existing method, it's going to have to use the same code anyway.

[preseinger]

GET allows, but does not require, server implementations to read/parse a body

sending a body with a GET request does not suggest the recipient server will receive that body, in general

[preseinger]

middleboxes are free to drop the body of any GET request, and generally do so

[adev_]

> middleboxes are free to drop the body of any GET request, and generally do so

Most middlebox will equally drop any HTTP verb which is not whitelisted.

Even the extension of WebDAV, which are 15 years old are still commonly blocked.

[preseinger]

blocking a request is fine, the request is stopped, the client gets an error

my point is that a middlebox that receives a GET request with a body may drop the body from the request and still forward the request onwards, without the body

these are categorically different outcomes