4 ms·

> GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decisi

> GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP. I've been sending request body along GET method for years now

huskyr 4mo ago
Apparently some load balancers drop the body.
- inigyou 4mo ago
  I expect all sorts of intermediaries may drop the body, since having a body is forbidden by the standard. When it's your client talking to your server you can obviously do whatever you want - it doesn't cause problems until you want to involve third-party code, such as a reverse proxy (such as nginx) or a CDN. This includes proxies your customers may be using.
  - jmaw 4mo ago
    Where is it forbidden by the standard? I don't see anything in the GET definition in RFC 9110 [1] forbidding that. My understanding was that this is just undefined behavior. And not recommended due to your point about some third-party CDNs and RPs handling that UB in different ways. [1]: https://datatracker.ietf.org/doc/html/rfc9110#name-get https://datatracker.ietf.org/doc/html/rfc9110#name-get
    - giobox 4mo ago
      It's never been explicitly forbidden, just heavily discouraged in virtually every version of the spec. In the current 9110: > "A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain." "Content" is what the RFC calls a request body. The simplest argument against IMO is it makes caching more complex, as now the request body would have to be part of any cache keying etc, you can't just blindly key off the request + URI params for every single GET. There are plenty of other reasons to not do it. The spec expects responses to GETs generally to be cacheable: > "The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING])."
preisschild 4mo ago
> I've been sending request body along GET method for years now Generally not a great idea. With some http implementations this is not even possible (for example, fetch) https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... > You cannot include a body with GET requests And transparent caching might result in weird issues.
deleted 4mo ago
[deleted]
pseudohadamard 4mo ago
It does seem like a boil-the-ocean "fix". The entire planet has been kludging this with GET or POST as appropriate for the entire lifetime of HTTP, and now there's a proposal to do something that looks identical to POST but with slightly different semantics? So in exchange for solving a problem that's been dealt with (if not perfectly) forever you'd need to convince the entire world to adopt a new, incompatible mechanism? I'll give this one as much of a chance as BEEP. You've never heard of BEEP? Well, that's why.
treve 4mo ago
It's not a great idea. I wrote something a few years ago if it's interesting: https://evertpot.com/get-request-bodies/ https://evertpot.com/get-request-bodies/
notatoad 4mo ago
this was the response the last time this came up here. you can do all kinds of nonstandard stuff if you control the server, the client, and any steps in between. the point of standards is for when you don't control it all. put your server behind a managed load balancer or a caching proxy, and your get requests with bodies aren't going to do so well anymore.
Zardoz84 4mo ago
I work with a custom own maded web framewrok for Java (from before Spring was a thing!). A funny thing it's that treats GET and POST petitons identical when try to recover parameters from the petitions. So GET and POST get parametertes from URL and from BODY. And this made some weird bugs many years ago, when in some case, we got repeated parameters in URL and BODY, trigering the framewrok to think that must put it on a List and pass it to the service method.
_betty_ 4mo ago
what do servers/proxies do when they don't recognise the verb?

huskyr 4mo ago

Apparently some load balancers drop the body.

inigyou 4mo ago
I expect all sorts of intermediaries may drop the body, since having a body is forbidden by the standard. When it's your client talking to your server you can obviously do whatever you want - it doesn't cause problems until you want to involve third-party code, such as a reverse proxy (such as nginx) or a CDN. This includes proxies your customers may be using.
- jmaw 4mo ago
  Where is it forbidden by the standard? I don't see anything in the GET definition in RFC 9110 [1] forbidding that. My understanding was that this is just undefined behavior. And not recommended due to your point about some third-party CDNs and RPs handling that UB in different ways. [1]: https://datatracker.ietf.org/doc/html/rfc9110#name-get https://datatracker.ietf.org/doc/html/rfc9110#name-get
  - giobox 4mo ago
    It's never been explicitly forbidden, just heavily discouraged in virtually every version of the spec. In the current 9110: > "A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain." "Content" is what the RFC calls a request body. The simplest argument against IMO is it makes caching more complex, as now the request body would have to be part of any cache keying etc, you can't just blindly key off the request + URI params for every single GET. There are plenty of other reasons to not do it. The spec expects responses to GETs generally to be cacheable: > "The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING])."

preisschild 4mo ago

> I've been sending request body along GET method for years now Generally not a great idea. With some http implementations this is not even possible (for example, fetch) https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... > You cannot include a body with GET requests And transparent caching might result in weird issues.

deleted 4mo ago

[deleted]

pseudohadamard 4mo ago

It does seem like a boil-the-ocean "fix". The entire planet has been kludging this with GET or POST as appropriate for the entire lifetime of HTTP, and now there's a proposal to do something that looks identical to POST but with slightly different semantics? So in exchange for solving a problem that's been dealt with (if not perfectly) forever you'd need to convince the entire world to adopt a new, incompatible mechanism? I'll give this one as much of a chance as BEEP. You've never heard of BEEP? Well, that's why.

treve 4mo ago

It's not a great idea. I wrote something a few years ago if it's interesting: https://evertpot.com/get-request-bodies/ https://evertpot.com/get-request-bodies/

notatoad 4mo ago

this was the response the last time this came up here. you can do all kinds of nonstandard stuff if you control the server, the client, and any steps in between. the point of standards is for when you don't control it all. put your server behind a managed load balancer or a caching proxy, and your get requests with bodies aren't going to do so well anymore.

Zardoz84 4mo ago

I work with a custom own maded web framewrok for Java (from before Spring was a thing!). A funny thing it's that treats GET and POST petitons identical when try to recover parameters from the petitions. So GET and POST get parametertes from URL and from BODY. And this made some weird bugs many years ago, when in some case, we got repeated parameters in URL and BODY, trigering the framewrok to think that must put it on a List and pass it to the service method.

_betty_ 4mo ago

what do servers/proxies do when they don't recognise the verb?