[HN Gopher] The HTTP QUERY Method specification
___________________________________________________________________
The HTTP QUERY Method specification
Author : andyk
Score : 75 points
Date : 2023-05-27 17:09 UTC (5 hours ago)
(HTM) web link (httpwg.org)
(TXT) w3m dump (httpwg.org)
| bornfreddy wrote:
| Requiring every proxy and web server to implement their own cache
| hashing algorithm, especially one that should ignore encoding-
| specific "non-consequential" parts, sounds like a monumentally
| bad idea.
| thwarted wrote:
| The cache is local to the proxy or web server, it doesn't
| matter what the hashing algorithm is as long as the cache
| accurately returns cached results given the same inputs. The
| semantic meaning of "input" is different for if it's a proxy or
| if it's the origin. The origin web server could very well cache
| based on the result of post processing and validation of the
| input, while a proxy should cache based on a much more strict
| (exact series of bytes) interpretation of the input.
|
| This is no different than how any other caching proxy is
| expected to operate given a set of inputs. It's never been up
| to the proxy to interpret if the queries "name=joe%20user" and
| "first=joe&last=user" are the same, it just passes the input
| along to its upstream and then locally stores the result,
| assuming that the same input will occur again and save a trip
| to upstream.
| preseinger wrote:
| you're papering over the important details
|
| namely, urls are finite, bodies are infinite
| franky47 wrote:
| While you *can* do the same with a GET (include data in the
| body), it's not spec-compliant for servers to parse and interpret
| this data.
|
| https://stackoverflow.com/questions/978061/http-get-with-req...
|
| When designing an API, and if spec compliance is not key, I
| wonder if client-compliance would become the issue (clients
| refusing to emit a GET body).
| mgaunard wrote:
| Parsing the body of GET can be added as an extension, same as
| adding this new QUERY method.
| DaiPlusPlus wrote:
| Many "WAF" (Web-Application Firewalls) and reverse-proxies
| are configured to block "unusual" traffic though, including
| GET-with-body - but I feel that this approach is like how
| (around 2000-2006) everyone switched from high-performance or
| legacy binary protocols to XML/SOAP-over-HTTPS to avoid
| corporate firewall headaches.
| thwarted wrote:
| There will most likely be problems with such web-
| application firewalls anyway, since those same firewalls
| will probably reject HTTP methods that they don't know
| about.
|
| But adding a new new method is probably overall better and
| matches people's understanding of the implementation and
| interpretation of GET, even if (with extensions) GET _can_
| have a body people don 't think of it like that. So a new
| method with defined semantics and interpretation avoids a
| whole bunch of sideshow debate about if GET with a body is
| possible or appropriate.
| preseinger wrote:
| middleboxes are free to drop the body of any GET request, and
| generally do so
| BugsJustFindMe wrote:
| > _it 's not spec-compliant for servers to parse and interpret
| this data._
|
| That's wrong. A lot of people just don't understand the
| difference between SHOULD and MUST when reading standards. The
| standard just says that you shouldn't rely on servers accepting
| it unless they tell you.
| andyk wrote:
| Saw this mentioned by @dragonwriter in the discussion at
| https://news.ycombinator.com/item?id=36095032 but it seemed
| buried/easy to miss there. Also the article that thread is
| discussing is from 2021, whereas this was just published
| yesterday.
| betimsl wrote:
| Love it :)
| deepzn wrote:
| previously it was titled SEARCH. I like query better personally,
| as it kind of aligns with SQL like requests.
|
| Here's a great post on it- https://httptoolkit.com/blog/http-
| search-method/ and earlier HN thread-
| https://news.ycombinator.com/item?id=36095032
| paddw wrote:
| This seems like it would introduce a tremendous amount of work to
| solve a problem that basically does not exist. You can just
| handle your POST request idempotently. We should just live with
| the semantics we have.
| preseinger wrote:
| HTTP defines the POST method explicitly as non-idempotent
| xrisk wrote:
| did you even read the article? it describes why this is a bad
| idea -- it's not just _your_ server that's handling the
| request, it's all the other middleboxes in between.
| crooked-v wrote:
| With POST, you can't know at a system level if it's safe to
| cache the response or not.
| DaiPlusPlus wrote:
| Cache-Control response headers?
| preseinger wrote:
| insufficient
| paulddraper wrote:
| I see the need, and good write up, but just use this for the
| definition of GET body.
|
| Nothing in the existing spec prevents GET from having a body,
| though there isn't currently a semantic meaning to it.
|
| This would fit perfectly, be more compatible and result in a
| simpler spec and protocol.
| rektide wrote:
| We'd have to change the behavior of browsers & server
| implementations to do this. Itvs much less risky, much more
| managable change, to do this with a new more deliberate
| difference. It'll make it clear that the new behavior is
| intended.
| paulddraper wrote:
| > We'd have to change the behavior
|
| But you wouldn't for QUERY?
|
| This is backwards compatible and in many cases will just work
| since GET with body is already syntactically valid.
| janderland wrote:
| I think they mean we'd have to modify existing features.
| There are probably assumptions made in code and tests
| around how GET will be used. Instead of breaking those
| assumptions and potentially implementing new bugs in an old
| feature, you can use a completely new HTTP method with
| completely new code paths. Older feature remains unchanged.
| rektide wrote:
| QUERY is an explicit negotiating forwards. It would need
| support, but nothing with existing systems would change. No
| web page which accidentally tried to send a http bodied GET
| would start having new behavior.
| preseinger wrote:
| middleboxes are free to drop the body of a GET request, and
| many do
| cientifico wrote:
| Caching the body scares the hell out of me.
|
| If the params for the search are so many or so big that they
| don't fit in a single url, how could you use that as a cache
| key?
|
| Right now you can:
|
| * Pass the arguments as parameters
|
| * Pass them on the request body. I personally done it on apis
| for games in unity/ios/android for almost a decade). Other
| products like Elasticsearch count on that as part of the core
| product.
|
| * Semantically create searches in the server with POST /search
|
| In the previous two examples, you can return a redirect to the
| search results (like /searches/33) with perfect
| caching/indexing, and delegate to the server the cache
| algorithms.
|
| With things like Vary, Etags, Conditional fetchs, Content-
| Encoding, Content-Type, Cache-Control, Expires that the spec
| barely grasp, adding a huge body is something that a cache
| server/cdn will not implement.
|
| So again. What is this spec solving?
| thwarted wrote:
| > If the params for the search are so many or so big that
| they don't fit in a single url, how could you use that as a
| cache key?
|
| The way many caching systems work, by hashing the body and
| using the hash as the cache key.
| lozenge wrote:
| Despite the spec, a lot of clients, load balancers, and server
| libraries can't handle GET with a body.
| codetrotter wrote:
| I was wondering which versions of HTTP will this be added to
|
| Thinking, will it be possible to send HTTP/1.1 QUERY requests?
| HTTP/2 QUERY requests?
|
| Or will it be for HTTP/3 or something even higher?
|
| Well the examples given in the document seems to indicate that it
| will be possible to use with HTTP/1.1 even
| QUERY /contacts HTTP/1.1 Host: example.org
| Content-Type: example/query Accept: text/csv
| select surname, givenname, email limit 10
| treve wrote:
| Any good HTTP implementation will support any HTTP method. If a
| HTTP method is not recognized, it will basically be treated as
| if it's a POST method.
___________________________________________________________________
(page generated 2023-05-27 23:00 UTC)