Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP Query Method

ietf.org

Post reply on HN
Print view View original

101–110 of 136 posts

Re: The HTTP Query Method

#101

Post by LudwigNagasena »

hnlmorg wrote: post #65
LudwigNagasena wrote: post #44

Earlier quoted context omitted.

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

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 infra…

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

Re: The HTTP Query Method

#102

Post by locknitpicker »

chrisandchris wrote: post #74
gridlocdev wrote: post #17

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.

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.

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

Re: The HTTP Query Method

#103

Post by ahtihn »

Veserv wrote: post #86
pcthrowaway wrote: post #14

Earlier quoted context omitted.

I think the idea is that POST creates a record (and in theory fails if that record already exists). I guess the commenter above is saying that if you inverted that (fail when the record doesn't exist, return the record if it does) it would be similar to QUERY? Not sure if I agree with that, but PUT's return semantics are a bit vague.. it often returns partial or combined records, or just a 200 OK (with or without a r…

No, I was referencing the example in the article in literally the very first section showing and explaining how POST endpoints are used for fetching data when GET endpoints are too limited. This is literally their motivating impetus for the QUERY request type. When considered abstractly, POST is just a request body and a response body. This is obviously powerful enough to define any behavior you want; it is just a ch…

> The fact that this endpoint guarantees QUERY behavior is just part of the documented server interface

And how do you communicate this behavior to the client (and any other infrastructure in-between) in a machine-readable way?

Re: The HTTP Query Method

#104

Post by [deleted] »

chrisandchris wrote: post #74
gridlocdev wrote: post #17

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.

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.

[deleted]

Re: The HTTP Query Method

#106

Post by hnlmorg »

LudwigNagasena wrote: post #101
hnlmorg wrote: post #65

Earlier quoted context omitted.

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 infra…

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

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.

Re: The HTTP Query Method

#107

Post by fogzen »

What’s wrong with POST’ing a report?

POST to /reports with the query parameters in the body. Respond with bookmarkable, cacheable /reports/id and GET /reports/id

And that’s only necessary for huge, complex queries. If filtering some resources doesn’t fit into the URL you might want to rethink what you’re doing.

Re: The HTTP Query Method

#108

Post by onfir3 »

The convention for internal "Query" routes in my company is just a Post with a path starting with "/queries" This is taken care of in eg. our retry middleware.

Not as good as a standardized idempotent Method, but good enough for the time being till they finally approve this as RFC

Re: The HTTP Query Method

#109

Post by Hackbraten »

znpy wrote: post #89
Hackbraten wrote: post #80

Earlier quoted context omitted.

> please use the IETF Datatracker URL. On my phone, your Datatracker link results in an unreadable mess of a page due to the hard-coded line breaks in the plaintext rendition of the RFC text (making it unreadable in portrait mode) and the huge sticky page nav (causing the content viewport to shrink vertically to almost zero in landscape mode). The HTML page behind OP's link reads just fine. > The best way to view an…

It reads decently in landscape mode, and i’m on a small screen (iPhone se 3rd gen).

It shows me only seven lines of text at a time [0], too few for me to read comfortably, let alone make sense of e.g. diagrams. Firefox on Librem 5.

[0]: https://0x0.st/KJZ_.png

Re: The HTTP Query Method

#110

Post by jtbaker »

bostik wrote: post #85
bruce511 wrote: post #37

Earlier quoted context omitted.

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.

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/...

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

I remember this pain, circa 2021 perhaps?

Post reply on HN