4 ms·

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.

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-request-body#983458 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).

mgaunard 3y ago
Parsing the body of GET can be added as an extension, same as adding this new QUERY method.
- DaiPlusPlus 3y ago
  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 3y ago
    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 3y ago
      It's not up to debate, GET does allow a body.
      - thwarted 3y ago
        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 3y ago
        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 3y ago
        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 3y ago
  middleboxes are free to drop the body of any GET request, and generally do so
  - adev_ 3y ago
    > 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 3y ago
      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
BugsJustFindMe 3y ago
> 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.

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.

mgaunard 3y ago

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

DaiPlusPlus 3y ago
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 3y ago
  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 3y ago
    It's not up to debate, GET does allow a body.
    - thwarted 3y ago
      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 3y ago
        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 3y ago
      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 3y ago
middleboxes are free to drop the body of any GET request, and generally do so
- adev_ 3y ago
  > 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 3y ago
    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

BugsJustFindMe 3y ago

> 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.