- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 4 Jul 2025 09:02:07 +0200
- To: Roy Fielding <fielding@gbiv.com>
- Cc: ietf-http-wg@w3.org
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 Friday, 4 July 2025 07:02:17 UTC