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 3 hours ago | parent | next [-]

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

	▲	magicalhippo 2 hours ago \| parent \| next [-]
		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/
	▲	degamad an hour ago \| parent \| prev [-]
		> ... 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.

▲

juliangmp 3 hours ago | parent | prev | next [-]

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 3 hours ago | parent | prev [-]

semantics become extremely relevant when "proxies" start caching.