- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Wed, 1 Jul 2026 17:54:42 +0900
- To: Ben Schwartz <bemasc@meta.com>, Jesse Wright <jesse.wright@jesus.ox.ac.uk>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I may have missed something, but if not, there's an additional condition: The query must result in the same response across time (and other conditions). Even with exactly the same query, it's easily possible that the response changes because the data on the server has changed. Regards, Martin. On 2026-07-01 06:49, Ben Schwartz wrote: > In my view it's worth clarifying a distinction between cases where (1) the > same client is repeating an old QUERY, or (2) many clients are issuing > identical QUERYs. > > Case 1 is already handled in QUERY with the "Location" response field. > > Case 2 is somewhat special. For it to be useful: > * Many clients must be sending the same QUERY as many other clients. (No > IDs or timestamps.) > * They must all be using a byte-identical encoding of the QUERY. (No JSON, > unless everyone is normalizing it somehow.) > * The QUERY must be pretty large. > - If the client is optimizing for latency, it has to be larger than > bandwidth*RTT (several kilobytes at least) > - If the client is optimizing for bandwidth, it probably still needs to > be a few hundred bytes to outweigh the overhead of the extra packet > exchange, and larger than that to represent a material savings in > comparison to the response and other costs. > * The server needs to know that the QUERY is likely to be repeated, so the > response is cached. > > I can imagine some specialized use cases where all these conditions might > be true, such as a virus scanner service. The harder question, I think, > is: why should we try to model this in HTTP? Why not just let the > application deal with it? > > It would help to know more about your motivating use case. > > --Ben > > On Tue, Jun 30, 2026 at 9:02 AM Jesse Wright <jesse.wright@jesus.ox.ac.uk> > wrote: > >> Hi all, I would like to make it possible for HTTP QUERY to have cache hits >> on servers and CDN's without always needing to send the full request body - >> so as to minimize network traffic on queries with large request bodies. >> This could be achieved >> >> Hi all, >> >> I would like to make it possible for HTTP QUERY to have cache hits on >> servers and CDN's without always needing to send the full request body - so >> as to minimize network traffic on queries with large request bodies. >> >> This could be achieved as follows. The client sends a Content-Digest (RFC >> 9530) of the request content with Expect: 100-continue (RFC 9110) and >> withholds the body. On a miss the cache the usual 100 (Continue) would be >> sent. On a cache hit, the server answers immediately and never sends 100 >> (Continue), so the body is never uploaded: >> >> QUERY /search HTTP/2 >> Content-Type: application/sql >> Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=: >> Expect: 100-continue >> >> (client withholds the request content) >> >> HTTP/2 200 OK >> Content-Type: application/json >> Cache-Status: ExampleCache; hit; detail=request-content-digest >> >> (result served from cache; the query body was never sent) >> >> I would like to gauge from the group whether there is interest in solving >> this problem. If yes: >> >> 1. Is Expect: 100-continue the right primitive, or would a dedicated >> request precondition be cleaner? >> 2. Where should it live? Three options, and I'd welcome direction: >> 1. revise RFC 10008 to fold it in; >> 2. a short companion document that formally Updates RFC 10008; >> 3. an independent extension. >> >> >> A rough sketch (kramdown-rfc source) is here: >> https://gist.github.com/jeswr/7425f74439733762eb347f0a0c199339 >> >> This idea was originally raised in the following issue: >> https://github.com/httpwg/http-extensions/issues/3469 >> >> Kind Regards, >> Jesse Wright >> DPhil Computer Science >> Jesus College >> >> mailto:jesse.wright@cs.ox.ac.uk <jesse.wright@cs.ox.ac.uk> >> https://www.cs.ox.ac.uk/people/jesse.wright/ >> <https://urldefense.com/v3/__https://www.cs.ox.ac.uk/people/jesse.wright/__;!!Bt8RZUm9aw!6K_tkqTWDZZfNrYkFxMHG_mJBYdDVUUrxqFMdaJdK7KrPbS8XkLqKSq-dmLCRC29bBb9K1zqNzHv94i5gKFQYD-oeA$> >> https://www.linkedin.com/in/jesse-wright-49823a132/ >> <https://urldefense.com/v3/__https://www.linkedin.com/in/jesse-wright-49823a132/__;!!Bt8RZUm9aw!6K_tkqTWDZZfNrYkFxMHG_mJBYdDVUUrxqFMdaJdK7KrPbS8XkLqKSq-dmLCRC29bBb9K1zqNzHv94i5gKH0qkuQEA$> >> Book a meeting: https://cal.com/jesse-wright-zdbdal/public >> <https://urldefense.com/v3/__https://cal.com/jesse-wright-zdbdal/public__;!!Bt8RZUm9aw!6K_tkqTWDZZfNrYkFxMHG_mJBYdDVUUrxqFMdaJdK7KrPbS8XkLqKSq-dmLCRC29bBb9K1zqNzHv94i5gKFQ2Q-sRg$> >> Mobile: +44 7862 381 515 >> WhatsApp: +61 468 669 019 >> >> *My work day may look different than yours. Please do not feel obligated >> to respond outside of your normal working hours.* >>
Received on Wednesday, 1 July 2026 08:54:51 UTC