Re: RFC 10008: caching QUERY without re-sending the request body

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.*
>