[Rapzid]

Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server.

A whole new method whose semantics don't really fit with the others is.. An odd way forward.

[CommonGuy]

Proxies are allowed to drop bodies of HTTP GET requests.

RFC 9110 states:

> [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..]

> A client SHOULD NOT generate content in a GET request [..]

[degamad]

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

You left out the important part.

[lightningspirit]

How does the origin server indicate that?

[Rapzid]

In or out of band. ie an API.

[magicalhippo]

Even HTTP 1.0 RFC[11] is fairly clear on this, although it doesn't explicitly spell it out like RFC 9110. GET requests should only consider the Request-URI and request bodies should only be included if the method calls for it.

[1]: https://www.rfc-editor.org/info/rfc1945/

[juliangmp]

Yeah I always disliked that there's this idea that you can't put a body on a GET request. Iirc openapi generators goes out of its way to not support that which has lead to me writing a small rant into an API specification before to explain why the get_xyz uses POST...

[thewisenerd]

semantics become extremely relevant when "proxies" start caching.

[Rapzid]

A lot of the RFCs are flavored by the lack of https and prevalence of forward proxies run by the ISPs to improve perceived speed and reduce their network loads.. Back in the day.

By my estimation, that's why they explicitly call out only the client and origin can know what a GET body means; proxies should forward as-is and ignore.

Those days of ISP forward http proxies are gone, but those semantics are still fine; the body means what the origin and client agree it means.