RFC 10008: The new HTTP Query Method
rfc-editor.org
RFC 10008: The new HTTP Query Method
1–10 of 189 posts
Re: RFC 10008: The new HTTP Query Method
#2query strings always had size limit, seems this new type will solve it which will be really good.
Re: RFC 10008: The new HTTP Query Method
#3Wouldn’t just putting an etag on POST requests accomplish the same thing? If I’m understanding it the server has to maintain state to ensure idempotency.
Re: RFC 10008: The new HTTP Query Method
#4Wait, it's already past 10 thousand?
Re: RFC 10008: The new HTTP Query Method
#5If this is actually going to replace GET requests w/ query strings in the wild, Im very much hoping for browser bookmarks to support keeping request parameters.
Re: RFC 10008: The new HTTP Query Method
#6If this is actually going to replace GET requests w/ query strings in the wild, Im very much hoping for browser bookmarks to support keeping request parameters.
Probably won't. Probably will replace whenever POST is currently used for a query.
Re: RFC 10008: The new HTTP Query Method
#7Wouldn’t just putting an etag on POST requests accomplish the same thing? If I’m understanding it the server has to maintain state to ensure idempotency.
QUERY is GET with a request body. So it must be safe, not just idempotent. Where safe means it has no significant side-effects. Typically servers will not keep any state for QUERY requests.
There is one interesting variant though, which uses state: The client sends a QUERY containing the full query, and the server returns a url usable with GET with which this query can be triggered in the future. Similar to prepared statements in SQL databases.
Using QUERY for GraphQL queries (not mutations) would be a good match. These only read data, but are sometimes bigger than the url length limit.
Re: RFC 10008: The new HTTP Query Method
#8This makes me happy tbh, I was never a fan of creating `POST /search` endpoints when working with robust APIs
Re: RFC 10008: The new HTTP Query Method
#9Wouldn’t just putting an etag on POST requests accomplish the same thing? If I’m understanding it the server has to maintain state to ensure idempotency.
QUERY is GET with a request body. So it must be safe , not just idempotent . Where safe means it has no significant side-effects. Typically servers will not keep any state for QUERY requests. There is one interesting variant though, which uses state: The client sends a QUERY containing the full query, and the server returns a url usable with GET with which this query can be triggered in the future. Similar to prepare…
Ideally, libraries like FastAPI, etc. could be configured to translate QUERYs to GETs, until you can rewrite your code to automatically support both.
Re: RFC 10008: The new HTTP Query Method
#10Including 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 meaningful general caching strategy being bitwise compare of the request body (or a hash), which in a hostile scenario implies cache busting would be trivial.
This invokes multiple semantic oddities in one go with obvious difficulties for a very niche use case. If I'm writing a service that needs complex filtering or complex input like an image, any form of caching (e.g. individual data columns of a join, or embeddings keyed by perceptual hashes of a decoded image input) is going to be far away from the HTTP layer and certainly unrelated to the exact bit representation of the request on the wire.
Why even bother trying to capture this in a generic way?
I would be far more inclined to try and capture this caching semantic as a new header for POST. Something like "Vary: request-body" or similar. Perfectly backwards compatible and perfectly ignorable for all but the 0.1% of CDN use cases where the behaviour might turn out useful