Hacker News Reader

Comment by tkiolp4 | Hacker News Reader

Wouldn’t be enough to “extend” GET so that it supports a body payload as well?

No, because that would make GET not-cachable by URL alone, which breaks systems that rely on the fact that it is.

A new method doesn’t break existing systems.

It sort of does, but support is spotty. I've tried using it only to have things like MITM proxies on my customers' corporate networks drop the body. It'd be a large push to get universal support. It may be more difficult than simply adding a new method.

But if a new method is needed, servers have to support it (e.g., by updating them to the next version that supports the new method). In the same sense, couldn’t that new version “just” not drop the body of GET requests?

In any case we are talking about updating servers.

The only software I have seen that does this is Elasticsearch - it works with their client libraries but I'm always worried there may be proxies and suchlike which don't support it.

They support POST as a fallback.

You can actually do that already. It's one of those things where the specification is a bit loose on this. Elasticsearch is an example of a product that supports doing a GET with a body to do search. Works fine but not all http clients allow you to do this so they also support POST.

Nice discussion on HTTP GET with a body here: https://stackoverflow.com/questions/978061/http-get-with-req...

TLDR. the http 1.1 spec was a bit vague on this and allowed people to send a body but specified that servers should ignore that if they did. Later updates of the 1.1 spec removed that sentence and actually allow this. The caveat that the spec mentions that some implementations may not support it.

So an update is not needed; it's already allowed.

I tend to not get too hung up on the meaning of http verbs. I sort of lost interest in the endless debates on this years ago. I like a well designed REST API of course and I try to follow the principle of the least amount of surprise when I implement one myself. Using exotic new experimental http verbs would be surprising. Using GET this way is also a bit surprising. I actually steer clear of using PATCH as well. Just use a PUT or a POST and move on.

Adding new verbs to HTTP is redundant as far as I'm concerned. Not really against it but where does it stop? And what do we get out of it? It doesn't sound like it's worth the trouble.

It already does.

Sort of, but it’s not that solid: https://datatracker.ietf.org/doc/html/rfc9110#name-get

(paragraph starting “Although request message framing is independent of the method used”)

The RFCs are clear that a server should ignore any body sent by a client after a GET request header. But RFCs don't matter; real life matters, and in real life there are lots of HTTP clients that can't make a GET request with a body. We had to go into our API and add POST support to every endpoint that was GET + body because there was a long tail of clients that couldn't manage to make the GET request. In practice, support is NOT widespread enough to rely on GET + body requests.

It’s not exhaustive though. Many servers and proxies support it, but not all. For instance, GCP load balancers do not, but ALB does. At least that was case a few years ago.

Reply on news.ycombinator.com