Why not just define the semantics of a GET request body?
Proxies often delete it
They could be updated to not delete it, like they would require for this new method anyway.
RFC 10008: The new HTTP Query Method
81–90 of 189 posts
Re: RFC 10008: The new HTTP Query Method
#82Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…
One example - I'm building an MCP server at the moment for a database I'm working on. In ChatGPT I want to do dry-run posts first that roll back before committing - both are POST requests with a property - and it loves to trigger the safety layer in the tools (for various reasons, it's hard to debug exact causes)
But I think this would make it better - QUERY before POST means different request types, not just the same with a safety flag.
Re: RFC 10008: The new HTTP Query Method
#83I wonder if HTML forms will add support for QUERY: This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.
One oddity of forms: the result of a form POST is a page that has a location (the URL) but that cannot loaded via that location. As far as I know, the fact that the page is a POST and not a GET is not stored anywhere visible to the user or to JS. And refresh works oddly. If method=QUERY were added, there would be a new variety of this weirdness.
At least browsers wouldn't have to warn users that they'd be resubmitting data if they reload the page after submitting a query form, since query requests are intended to be idempotent
Re: RFC 10008: The new HTTP Query Method
#84Earlier quoted context omitted.
Thanks for the explanation! I still don’t get how idempotency can typically be ensured without state. It very much depends on data model and application design. Even side effects like using a user’s lookup quota need to be handled at a higher layer than HTTP (I think?).
Yes it varies. Using the QUERY method doesn't automatically mean your app is idempotent - it means the browser, and any intermediaries, can assume it's idempotent. So when you go forward and then back they're free to reissue the request and you won't get the "this may repeat whatever you just did" popup. If it's not actually idempotent but you're telling the browser it is, of course you may cause bugs. Same as GET.
I think PUT, which is idempotent, would still require the "repeat action" warning, since it will overwrite any changes that happened to the same resource in the mean time (unless used with `if-match` or similar). QUERY won't require such warnings because it's safe, not just idempotent.
Re: RFC 10008: The new HTTP Query Method
#85Earlier quoted context omitted.
Not all usage scenarios are the public internet, and something doesn't have to be useful on the public internet to be standardized. Realistically, systems for the public internet will use a secure hash as the cache key so it'll always be the same size. The cache key already includes a URL that can be very long, and an arbitrary set of header values.
Except that by definition, in a URL the data has no implicit meaning so for a cache hit you need an exact match, including order and case, but for a list of POST parameters, they could legitimately be in any order and so you can't just hash it all as a blob, you need to sort the keys, possibly copy data around (unless using keys plus hash), probably allocating more memory, etc. I'm pretty certain we'll see at least o…
POST/QUERY data can be in any format. Who are you to say order doesn't matter? Are you sure you can even parse it? Mine is in DES-encrypted (with key "password") base85 DER, you really gonna implement that in your proxy?
Re: RFC 10008: The new HTTP Query Method
#86Re: RFC 10008: The new HTTP Query Method
#87Earlier quoted context omitted.
One oddity of forms: the result of a form POST is a page that has a location (the URL) but that cannot loaded via that location. As far as I know, the fact that the page is a POST and not a GET is not stored anywhere visible to the user or to JS. And refresh works oddly. If method=QUERY were added, there would be a new variety of this weirdness.
At least browsers wouldn't have to warn users that they'd be resubmitting data if they reload the page after submitting a query form, since query requests are intended to be idempotent
You still get the nastiness that the Sec-Fetch-* state gets mostly trashed when you hit refresh. And someone would need to figure out how CORS preflight interacts with refresh, which is not currently an issue with POST. (The current "simple request" behavior or whatever it's called is a real mess and is the cause of a lot of CSRF vulnerabilities.)
Re: RFC 10008: The new HTTP Query Method
#88Why not just define the semantics of a GET request body?
There's countless proxies in the wild that would not behave correctly with an RFC-defined GET-with-body, and there's no way for a client to know if that's the case.
QUERY has the advantage of getting default behaviour from most proxies (which at least is well behaved even if inefficient). If there are any proxies that just drop QUERY requests, at least they won't silently mangle the request.
This is the same way that instead of improving how HTTP 301 was specified, HTTP 308 was created. It's a pragmatic move.
Re: RFC 10008: The new HTTP Query Method
#89This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol.
HTTP is transfer protocol. It should not ever imply anything at the business level.
Yes REST made it's worst mistake out if it by giving a meaning to the verb.
Yes proxies rule how the body is re-interpreted in spite of the will of the sender (wtf).
But the original RFC states clearly that any verb can be used. This is how WebDav normalised its own.
But playing fancy by introducing a change that all HTTP implementation will have to honor is a very bad and irrational choice.
Re: RFC 10008: The new HTTP Query Method
#90Earlier quoted context omitted.
Forms, HTTP implementations, public API surfaces, and all for what exactly. Introducing a new verb for this feels profoundly misplaced
Idempotency is an important attribute for correctness. Yep, you can document that POSTing to $ENDPOINT is idempotent, but you can't communicate that to caching layers throughout the network. QUERY, by definition, is idempotent and cacheable.
Great point. I wish more people realized that intuitively.