[deleted]
RFC 10008: The new HTTP Query Method
121–130 of 189 posts
Re: RFC 10008: The new HTTP Query Method
#122I 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.
Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347
What’s the use case for that?
Re: RFC 10008: The new HTTP Query Method
#123Earlier quoted context omitted.
I would use a hash of the body content (the query) as a URL parameter /?hash=123456789
Why? That's pushing more work to do both on yourself and the cache.
Actually this is a use-case supported by this RFC [1]. You accept an arbitrary QUERY /search/ and you cache it on your side (or in a middle box somewhere such as a CDN edge) you can return in your response:
Location: /search/?queryHash=SOMECDNHASH
Sure, it is more work for your webserver to compute that and potentially the browser to cache it's knowledge of that QUERY, but it potentially gives you an advantage in keeping things like CDN edge caches generally aware of client/browser caches in a way that can be performance optimized.
Re: RFC 10008: The new HTTP Query Method
#124Earlier quoted context omitted.
Query parameters are length-limited, because HTTP URIs are: https://www.rfc-editor.org/info/rfc9110/#section-4.1-5 . There is no expectation for arbitrarily long HTTP URLs to be functioning.
Your link doesn't say URIs are length-limited
They are in the sense that the recommended supported length is only 8000 bytes. There are no such specified length recommendations for HTTP body size.
Re: RFC 10008: The new HTTP Query Method
#125Why not just define the semantics of a GET request body?
It would be a potentially breaking change so out of an abundance of caution likely would require (or need to wait for) a new version of HTTP like HTTP/4.0. On the other hand, adding an entirely new Method potentially can be applied across HTTP versions. It's possible for an HTTP/1.1 server to accept QUERY today under this RFC, it doesn't need to wait for and upgrade to HTTP/4.0 service, whatever that would entail. (Especially in the Postel's Law world where HTTP/1.1, HTTP/2.0, and HTTP/3.0 are all living side-by-side and are very different protocols under the hood.)
Re: RFC 10008: The new HTTP Query Method
#126Earlier quoted context omitted.
I expect all sorts of intermediaries may drop the body, since having a body is forbidden by the standard. When it's your client talking to your server you can obviously do whatever you want - it doesn't cause problems until you want to involve third-party code, such as a reverse proxy (such as nginx) or a CDN. This includes proxies your customers may be using.
Where is it forbidden by the standard? I don't see anything in the GET definition in RFC 9110 [1] forbidding that. My understanding was that this is just undefined behavior. And not recommended due to your point about some third-party CDNs and RPs handling that UB in different ways. [1]: https://datatracker.ietf.org/doc/html/rfc9110#name-get
It's never been explicitly forbidden, just heavily discouraged in virtually every version of the spec. In the current 9110:
> "A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain."
"Content" is what the RFC calls a request body. The simplest argument against IMO is it makes caching more complex, as now the request body would have to be part of any cache keying etc, you can't just blindly key off the request + URI params for every single GET. There are plenty of other reasons to not do it.
The spec expects responses to GETs generally to be cacheable:
> "The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING])."
Re: RFC 10008: The new HTTP Query Method
#127Earlier quoted context omitted.
Depends whether your form submission should expect side effects or not. Most forms submissions have side effects. If the effect is truly idempotent, wouldn't PUT be a better verb? That is also supposed to be idempotent.
GET and QUERY are both idempotent.
Hold my beer!
Re: RFC 10008: The new HTTP Query Method
#128Earlier quoted context omitted.
Well, because it is more code. Current caching software caches by headers + query string. It now needs to be expaned to cache by body too. It feels very pointless and there is no drawback of just using POST
Is caching not the primary reason to use this over POST? You should never want to cache POST requests.
No. Being idempotent, it also lets the browser/client/reverse proxy retry it if it fails.
Re: RFC 10008: The new HTTP Query Method
#129Earlier quoted context omitted.
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?
Maybe my knowledge is out of date in terms of how people generally use POST nowadays, but AFAIK multipart/form-data is still the most common encoding for data and occasionally application/x-www-form-urlencoded.
Both of these, the key values can be in any order with the same interpretation. That's kind of a moot point for POST method, because they should never be cached anyway, but for the new QUERY method it'd be reasonable to expect a cache hit whenever the parameters are the same regardless of order.
My point is that for a GET, you can't assume that the order isn't important, because the URL is an opaque string by the time it hits the cache. However, POST (and now QUERY) explicitly says what the coding is, so for instance with application/x-www-form-urlencoded we can be sure that the parameters can be in any order without changing the meaning. You cannot infer that from a URL itself.
As to your point, yes you can use any other encoding you like to. But most systems don't do that, they use multipart/form-data.
Re: RFC 10008: The new HTTP Query Method
#130Earlier quoted context omitted.
Well, because it is more code. Current caching software caches by headers + query string. It now needs to be expaned to cache by body too. It feels very pointless and there is no drawback of just using POST
There is: your browser or other type of client does not know it can repeat a POST request if it fails, whereas a QUERY request can be freely repeated in case of errors.
Not freely. It is idempotent, not safe. So it still can have serious load consequences.