- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 9 Jul 2025 12:09:55 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org
I don’t think it will work at all. I think this is yet another doomed extension to HTTP because it doesn’t adhere to the existing architecture that has been proven to scale well because it forces developers, often unwillingly, to follow a single redirect on a non-time-critical response in order to enable a million hits on a cached response. Deploying body-scanners just to handle QUERY is doomed because the existing pipelines don’t work that way, on purpose. Yes, we could change our own origin code just for this extension, but it won’t work consistently for chained requests via multiple CDNs. We have zero desire for unchained traffic. I don’t expect to be right about this stuff all the time. A deployment might prove me wrong. But the specification should at least have a section in the introduction that explicitly discusses those tradeoffs and alternative designs. ....Roy > On Jul 4, 2025, at 12:03 AM, Mark Nottingham <mnot@mnot.net> wrote: > > Hi Roy, > >> On 26 Jun 2025, at 9:49 am, Roy T. Fielding <fielding@gbiv.com> wrote: >> >> IOW, I am not objecting to the idea of supporting QUERY as a "GET with a body" >> or a "POST with idempotence". That's fine. What I object to is the suggestion >> that QUERY might be cacheable without producing a URI, or that intermediaries >> might be encouraged to read an entire request body and canonicalize it >> on the off-chance that it might be a reusable, previously cached query. >> >> It's one step too far into the abyss. >> >> In contrast, we already have a safe and Web-positive mechanism to achieve >> caching with a Location-provided URI. > > I get that. On the other hand, we have growing GET-with-body abuse that causes its own set of issues. QUERY is designed to address these cases, but if it doesn't have a caching story, it's not going to be able to (as I mentioned, some are already including the request body in the cache key; that barrier has already been broken). > > Using a Location-provided URI adds a round trip and an abstraction / state that's likely to dissuade at least some people from using this mechanism, creating a disincentive for adoption. Those who would be willing to use that pattern would have already been using POST/201, after all. > > So in my mind, this is a case of balancing architectural purity against the need to address this use case -- and avoid the problems created by the current workarounds that people are using. YMMV, of course. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Wednesday, 9 July 2025 19:10:13 UTC