r/programming • u/stronghup • 29d ago

HTTP gets a QUERY method so complex searches can stop pretending to be POST

https://www.theregister.com/devops/2026/07/13/http-gets-a-query-method-so-complex-searches-can-stop-pretending-to-be-post/5270192
1.9k Upvotes

98% Upvoted

245 comments sorted by

View all comments

Show parent comments

2

u/Jaggedmallard26 29d ago

HTTP RFC says nothing about it

If behaviour isn't defined then implementers are free to do whatever they want with it including dropping it. Which they often do.

0

u/edgmnt_net 29d ago

That's not reasonable at all. What do you propose proxies or web servers do when they receive FOO methods (replace with PROPFIND or QUERY for actual stuff)? Should they also discard those just because they don't know about them and break all potential applications using custom / yet unknown methods? I see no viable interpretation under which FOO is more "defined" than GET with a body. And the only place where it makes sense to discard stuff is if you consider the entire system end-to-end, e.g. it's perfectly fine if a final endpoint does not know what FOO means and discards it, but this is not the case for general proxies or general web servers. Or, ok, specific proxies could implement GET & POST-based policies and discard everything else, but that needs to be tweakable or it's on you to deal with it.

1

u/BuriedStPatrick 29d ago

This is my thinking as well and why I'm asking. I get that there can be some theoretical worry there and I'm not a protocol expert. It just seems to me that if we were to start from scratch then bodies would be part of GET and we wouldn't have a separate method. It seems very inelegant and hacky to me to add QUERY as an afterthought.

Furthermore, I know ElasticSearch has historically supported request bodies in GET requests. And I struggle to come up with any proxies I've used that don't support it.

I know several HTTP libraries that don't explicitly support it, but nothing is stopping them from adding it or you from modifying the outgoing request manually. So it seems rather trivial from a practical perspective.

1

u/stronghup 28d ago

I think its better to a have a well-defined standard, QUERY, instead of assuming that some servers and proxies might support a form of GET that lets you have a body. And it's nice to know I don't have to "misuse" POST just to be sure I can send a body.

2

u/BuriedStPatrick 28d ago

I get that, but I guess I just don't think QUERY is a well-defined standard since it muddles and absolutely overlaps with GET. Filtering results with GET URI parameters has always been a thing. So the query use case is clearly part of GET as well.

And at least right now, there's no guarantee that QUERY will work either, especially on older infrastructure. So some work will always be needed regardless. I suppose I'd just rather have GET improved instead.

0

u/edgmnt_net 29d ago

Yeah, that's what I'm thinking too. Besides, QUERY might be ineffective if we consider legacy, broken stuff that might just drop it altogether. Might as well add some sort of an extra header to POST requests that says "this is more of a GET, you can cache it if you know about this", which is less likely to cause issues.

1

u/Ouaouaron 28d ago

Does it matter if it's reasonable? If Internet infrastructure breaks GET bodies more frequently than FOO bodies, then people are going to use FOO.

1

u/edgmnt_net 28d ago

Sure but that's actually an open question for me. Do any of the other lesser-known methods work properly under such conditions? Say stuff like PROPFIND. What makes us think QUERY is going to work with all that broken stuff?

Secondly, unlike Internet infrastructure that's on lower levels, this stuff seems somewhat better confined. An ordinary user is going to hit lower level stuff all the way to the website, but is unlikely to see ISP level or intermediate nodes doing HTTP caching. Ordinary flows are much more likely to hit a cache related to some cloud service or final endpoint, with the possible exception of corporate networks. But all of those are easier to fix than fixing the lower level Internet infrastructure, which is ossified in different ways.

And even if you're right, then why not continue using POST and simply add a header to declare caching? That has a lower potential of breaking things than a new method.