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

91–100 of 136 posts

Re: The HTTP Query Method

#91

Post by immibis »

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.

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

Re: The HTTP Query Method

#92

Post by Veserv »

locknitpicker wrote: post #82
Veserv wrote: post #6

Earlier quoted context omitted.

The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…

> A QUERY seems to be no more than a POST that documents it is idempotent. This is false. By design QUERY is both safe and idempotent. In the context of HTTP, safe means "read-only", whereas idempotent means that a method does not introduce changes on the server, and thus many requests have the same effect of posting a single request. The fact that the semantics of an operation is deemed safe has far-reaching implica…

> POST requests by design are neither safe not idempotent.

Outright wrong. You are allowed to handle POST requests in a safe and idempotent way. In fact, the existing usage of POST to query, the literal impetus for this proposal, has exactly that behavior.

What you are not allowed to do is assume that any arbitrary POST request is safe and idempotent.

Only a endpoint that is documented to support POST and that is documented to be idempotent and safe should be sent a POST with request body and expect a response body and be idempotent and safe.

In comparison, only a endpoint that is documented to support QUERY (which implicitly is documented to be idempotent and safe) should be sent a QUERY with request body and expect a response body and be idempotent and safe.

Do you not see how similar those two are?

In fact, you could trivially make every endpoint that handles QUERY just do the same thing if it gets a POST. So why should the client have to care what request type it sends? Why make a new request type?

Of course we should want to define a standardized QUERY server endpoint behavior and document whether a server endpoint has QUERY behavior on POST; that is valuable, but that should be left distinct from the client protocol and constraints.

The only benefit I can see for the client to distinguish QUERY from POST is that it allows intermediate layers to know the request is expected to be idempotent and safe on the incoming edge. The outgoing edge is not benefitted because the server can easily tag things appropriately.

I guess a cache can use that information to only begin allocating a cache entry if the client attempts a QUERY thus saving it from tentatively recording all requests on the chance that the server will say that the actual request that occurred is safe? And that is assuming that the cache does not coordinate with the server to just pre-know what endpoints are safe and idempotent. In that case all the cache would need to do is parse the location to verify if it matches a safe endpoint. So your benefit of adding a new request type is you get to “unga-bunga is QUERY” instead of doing some parsing and matching overhead.

Seems like a weak benefit relative to the benefits of a simpler and more uniform client protocol.

Re: The HTTP Query Method

#93

Post by girvo »

virtue3 wrote: post #79
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.

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.

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.

Re: The HTTP Query Method

#94

Post by dan-robertson »

Hackbraten wrote: post #80
zzq1015 wrote: post #64

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL. For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met... The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time. Also, the Datatracker URL is version-insensitive, so un…

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

When I open the link there is a table of information before the main RFC text. One row is titled ‘formats’ in bold and has a ‘htmlized’ link in it. Presumably that is what you were missing due to some understandable banner blindness.

Re: The HTTP Query Method

#95

Post by IanCal »

Hackbraten wrote: post #80
zzq1015 wrote: post #64

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL. For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met... The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time. Also, the Datatracker URL is version-insensitive, so un…

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

In the top section where there’s authors etc, there’s a format list. I didn’t see it the first time.

Re: The HTTP Query Method

#96

Post by idbehold »

JodieBenitez wrote: post #66
gbear605 wrote: post #25

At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet. The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implem…

And here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.

You also miss out on standardized HTTP caching mechanisms since those don't work with POST requests.

Re: The HTTP Query Method

#97

Post by ahoka »

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.

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

Re: The HTTP Query Method

#98

Post by locknitpicker »

Veserv wrote: post #92
locknitpicker wrote: post #82

Earlier quoted context omitted.

> A QUERY seems to be no more than a POST that documents it is idempotent. This is false. By design QUERY is both safe and idempotent. In the context of HTTP, safe means "read-only", whereas idempotent means that a method does not introduce changes on the server, and thus many requests have the same effect of posting a single request. The fact that the semantics of an operation is deemed safe has far-reaching implica…

> POST requests by design are neither safe not idempotent. Outright wrong. You are allowed to handle POST requests in a safe and idempotent way. In fact, the existing usage of POST to query, the literal impetus for this proposal, has exactly that behavior. What you are not allowed to do is assume that any arbitrary POST request is safe and idempotent. Only a endpoint that is documented to support POST and that is doc…

> Outright wrong. You are allowed to handle POST requests in a safe and idempotent way.

You clearly have no idea about what you are discussing. The definition of HTTP verb semantics clearly defines the concept of safe and idempotent methods. You should seriously learn about the concept before commenting on discussions on semantics. If that's too much work, RFC 9110 clearly and unambiguously states that only the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. Not POST.

It's completely irrelevant if you somehow implemented a POST method that neither changes the state of the server nor returns the same response whether you invoke it once or many times. All participants in a HTTP request adhere to HTTP's semantics, and thus POST requests are treated as unsafe and non-idempotent by all participants. That affects things like caching, firewalls, even security scanners. The HTTP specs determine how all participants handle requests, not just the weekend warrior stuff someone chose to write in a weekend.

Re: The HTTP Query Method

#99

Post by 8cvor6j844qw_d6 »

gaigalas wrote: post #63
Zambyte wrote: post #60

Earlier quoted context omitted.

What if the stuff you want to see can't be encoded in a URL?

I'm assuming the case here is lots of query params. Stuff like `?foo=bar&lorem=ipsum...`. Most likely, you would benefit from making a cirurgical mini-resource on the server. Introduce `/report/{id}`, and make it into a POST. The user POSTs to `/report`, and the answer is 201 (Created) or 202 (Accepted), with a `Location: /report/123` (generated short id). The thing you changed on the server, is that now that long li…

Hmm... sort of like an intermediate page?

That would explain a some of the design decisions. I had to do work on a old codebase and am studying it.

Thank you and the others too for the input.

Re: The HTTP Query Method

#100

Post by happytoexplain »

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…

I'm not following how this is different from not even using HTTP verbs. We didn't define them because it's the only possible way to declare client intent. They're cognitively useful for setting expectations, organization, announcing abilities, separation of concerns, etc. The fact that POST is today sometimes used in practice as a safe+idempotent query (i.e. a GET with a body) seems like the black sheep violating those useful qualities.
Post reply on HN