Elastic search (used to?) use HTTP body as parameters for a GET request. IIRC the HTTP specification doesn't (again, used to?) mandate GET request to have no HTTP body

Edit: Example of Elastic search API with GET body, now deprecated https://www.elastic.co/guide/en/elasticsearch/reference/7.7/...

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

The now obsolete specification https://www.rfc-editor.org/rfc/rfc2616 , obsoleted by https://www.rfc-editor.org/rfc/rfc9110

It still does. I don't think it violates the HTTP 1.1 specification but more that it is unspecified. It's just that a lot of http clients simply don't support doing HTTP GET with a body under the assumption that it is redundant / not needed / forbidden. Of course elasticsearch allows POST as an alternative.

People used to obsess a lot more about those HTTP verbs and their meaning a lot more than today. At least I don't seem to get dragged into debates on the virtues of PUT vs. POST, or using PATCH for a simple update API. If you use graphql, everything is a POST anyway. Much like SOAP back in the day. It's all just different ways to call stuff on servers. Remote procedure calls have a long history that predates all of the web.

GET requests with a body (unspecified in HTTP/1.1) reminds me of a similar case I encountered years ago: URL query params in a POST (an HTML form whose action attr contained a query string).

It's fairly common to have POST requests that have both a body and a query string. Or maybe not "fairly common" but it isn't really rare.

I know it's not that rare. But it is problematic.

I feel not obsessing about the meanings of HTTP verbs can, has, and will lead to security incidents and interoperability issues between middleware. Specifications where everyone gets to pick and choose different behaviors is a nightmare.

The obsession with fine-grained distinctions may be gone, but GET/POST is still relevant when talking about caching etc.

Interestingly though GET with data exists in the wild, and has for many years.

I manage a http library class, and a customer encountered an API that required a GET but with data. (think query parameters passed as XML).

I implemented that for the customer, and then implemented the reverse in the server class. I'm not going to say its used a lot, but it makes semantic sense.

Incidentally it also becomes true for DELETE which is another request typically without a body.

This is the first I've heard of QUERY though, so look forward to reading up on that.

Just a heads-up that cloudfront will return a 403 when it receives a GET with body.

It's documented and all but I still find it a peculiar choice. A 400 would have been better and less of a red herring.

It also produces an error on all Apple platforms, as it's banned by URLSession.

Is it that you can but you’re just told not to, even if both client and server agree on the semantics?

But you're only "supposed" to use POST with requests that add/modify data, or something silly like that.

In practice, QUERY is most useful for where you want a bunch of different verbs for the same endpoint and need a body.

QUERY is cacheable.

... in theory only. Not that many http cache programs support QUERY. And many HTTP middle-boxes bans non GET/POST verbs.

For now. Change has to come from somewhere.

And retry-able.

I do... but there are good reasons to not want to. If you read the linked spec you can learn for yourself

https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

In practice I think that’s exactly what many people do.

GraphQL is doomed?

No, this would actually be very useful for GraphQL API's.

nothing on the spec prevents arbitrary data on body of a GET. but clients and proxies are implemented by lazy people who make excuses they are preserving some legacy security feature or something and continue to ignore the spec.

The spec is actually pretty clear on this - do not specify a body on a GET request.

> A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

Previously it was "SHOULD ignore the payload".

It's nothing to do with laziness or security - people are writing spec conforming software. And indeed every library I've used allows interacting with a body, even on a GET.

> That's not what your quote says.

Yes it does. "No defined semantics" = "out of spec".

> I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.

You're out of the HTTP spec entirely.

How are you interpreting that English?

Not defined means, it could be anything. If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.

"out of spec" means that it is out of specification. It is literally not specified. You are doing something that is not specified. It is therefore an action that is out of specification. it is therefore out of spec.

If there was an utter ban, then it would be against specification and not compliant, not merely out of specification.

> "out of spec" means that it is out of specification. It is literally not specified.

That's not what it means at all. Being out of spec means the spec explicitly stating that a request with a body should be reject. If the spec does not state that a request with a body should be rejected then you are not required to reject a request which packs a body.

> Not defined means, it could be anything.

No, not defined means it's not within the purview of the spec. Spec doesn't care. You can send one. Maybe it'll work, maybe it won't, maybe it'll crash, maybe it'll be rejected, maybe some proxy along the way will strip it and the server won't even get it, maybe it'll get your client banned forever.

All of these are fine, because spec doesn't care.

> If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.

No, then it would be against spec, like HEAD with a response body.

You can do whatever the fuck you want, the spec defines what it defines.