[gridlocdev]

I can’t wait for QUERY to become an official RFC.

It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.

[chrisandchris]

There's nothing holding you back implementing the QUERY method right now - HTTP methods are standardized, but not limited to the standard. Obsviously it depends how proxies/servers/etc. might handle uncommon methods.

[immibis]

But that's the point, isn't it? Browsers, proxies and servers always assume POST isn't idempotent. When the user presses F5 the browser asks if they want to do the thing again. You can't prevent that without making it more complicated (e.g. send the request from JavaScript).

[locknitpicker]

> There's nothing holding you back implementing the QUERY method right now - HTTP methods are standardized, but not limited to the standard.

I think this comment is terribly naive. Technically you can write your own service to support verbs like LOL or FUBAR, but in practice your service is not only expected to be broken when passing requests through other participants you do not control but also it requires far more development work to integrate with existing standards. Take for example CORS. If a HTTP method is not deemed safe then client requests need to go through the unsafe flow with preflight requests and the like. Forget support for caching too, and good luck having your requests pass through proxies.

So what exactly did you achieved by using non-standard verbs?

If you chose to go the ignorant backwards incompatible way, you are better off not using HTTP at all and just go with some random messaging/RPC protocol.

[nine_k]

I won't be so strict. Even though a homebrew implementation won't be widely interoperable, an experience of its active development and use in a limited environment (e.g. within a company) would be valuable both to inform the RFC and to serve an example implementation.

[resonious]

Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!

[bruce511]

I have come across systems that use GET but with a payload like POST.

This allows the GET to bypass the 4k URL limit.

It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware).

I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.

[LudwigNagasena]

Sending a GET request with a body is just asking for all sorts of weird caching and processing issues.

[hnlmorg]

I get the GPs suggestion is non-conventional but I don’t see why it would cause caching issues.

If you’re sending over TLS (and there’s little reason why you shouldn’t these day) then you can limit these caching issues to the user agent and infra you host.

Caching is also generally managed via HTTP headers, and you also have control over them.

Processing might be a bigger issue, but again, it’s just any hosting infrastructure you need to be concerned about and you have ownership over those.

I’d imagine using this hack would make debugging harder. Likewise for using any off-the-shelf frameworks that expect things to confirm to a Swagger/OpenAPI definition.

Supplementing query strings with HTTP headers might be a more reliable interim hack. But there’s definitely not a perfect solution here.

[bruce511]

To be clear, it's less of a "suggestion" and more of a report of something I've come across in the wild.

And as much as it may disregard the RFC, that's not a convincing argument for the customer who is looking to interact with a specific server that requires it.

[LudwigNagasena]

Cache in web middleware like Apache or nginx by default ignores GET request body, which may lead to bugs and security vulnerabilities.

[hnlmorg]

But as I said, you control that infra.

I don’t think it’s unreasonable to expect your sysadmins, devops, platform engineers, or whatever title you choose to give them, to set up these services correctly, given it’s their job to do so and there’s a plethora of security risks involved.

If you can’t trust them to do that little, then you’re fuck regardless of whether you decide to send payloads as GET bodies.

And there isn’t any good reason not to contract pen testers to check over everything afterwards.

[locknitpicker]

> I have come across systems that use GET but with a payload like POST.

I think that violates the HTTP spec. RFC 9110 is very clear that content sent in a GET request cannot be used.

Even if both clients and servers are somehow implemented to ignore HTTP specs and still send and receive content in GET requests, the RFC specs are very clear that participants in HTTP connections, such as proxies, are not aware of this abuse and can and often do strip request bodies. These are not hypotheticals.

[bostik]

Elasticsearch comes to mind.[0]

The docs state that is query is in the URL parameters, that will be used.I remember that a few years back it wasn't as easy - you HAD to send the query in the GET requests body. (Or it could have been that I had a monster queries that didn't fit through the URL character limits.)

0: https://www.elastic.co/docs/api/doc/elasticsearch/operation/...

[jtbaker]

> you HAD to send the query in the GET requests body.

I remember this pain, circa 2021 perhaps?

[bostik]

Probably closer to 2019. Maybe the optionality is a relatively new feature then.

[virtue3]

I think graphQL as a byproduct of some serious shenanigans.

"Your GraphQL HTTP server must handle the HTTP POST method for query and mutation operations, and may also accept the GET method for query operations."

Supporting body in the get request was an odd requirement for something I had to code up with another engineer.

[girvo]

And the whole GET/POST difference matters for GraphQL at scale: we saved a truckload of money by switching our main GraphQL gateway requests to GET wherever possible.

[akvadrako]

Servers can support it but not browsers.

[carlosneves]

And oftentimes some endpoints simply hit the max URL length limit and need a proper body. I thought we ought to already be using this method. Seems quite fitting for fulfilling GETs with bodies.

[ahoka]

Maybe send the body in a close envelope as some software might also write the request body contents to disk or log it.