111–120 of 189 posts
Use the QUERY method in your http query to query search results. Do not add query parameters. I think the name is confusing because the term 'query' is already used to refer to http requests in general. Just the title of the RFC confused me.
Edit: ah, they declare QUERY as "safe" meaning no side effects, for cacheability. My mistake.
I 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.
Earlier quoted context omitted.
Proxies often delete it
They could be updated to not delete it, like they would require for this new method anyway.
i actually agree with you, i don't comprehend why we're adding anything to HTTP like this, it is basically already deprecated. The modern API is WebTransport, if you want to make caching better for WebTransport, do it there.
Including 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…
Exemple:
``` QUERY /search HTTP/1.1 Content-Type: application/json
{ "filters": { "region": "asia", "status": "active" }, "sort": "created_at", "limit": 500 } ```
can answer
``` HTTP/1.1 303 See Other Location: /queries/results/f3a9c1d7 ```
And then you can access later `/queries/results/f3a9c1d7` using a pure GET call, and cache this instead
Why is that better than a longer URL?
Semantically it identifies the resource. And it must be included in the cache key.
True, not everything supports long URLs. But not everything supports QUERY either, so it’s an absurd argument.
I 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.
This is better solved with the post redirect get pattern.
QUERY on the other hand makes sense for cases where the request doesn't cause any state changes on the server, and there is no resource to redirect to.
Earlier quoted context omitted.
Agree. They should not delete the body in the first place.
If we're going to play the "should" game, whatever originated the body "shouldn't" have because the spec says that's illegal. Although we could also go with, a proxy shouldn't delete the body, it "should" reject the request outright as ill-formed. The meta-point I'm making here, which I'm sure will be missed if I don't spell it out, is that if we're going to talk about what "should" be done when it is explicily out o…
For a very long time, the spec did not say it's illegal. In fact, RFC 2616 (that has been defining the HTTP/1.1 for 15 years) says that
A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.