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

Hi Jesse.

I can't speak to whether I have any interest in this. I'll let others speak up on that front. However, see some responses to technical aspects in line:

On Mon, Jun 29, 2026, at 23:50, Jesse Wright 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 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 am not a caching expert, so I expect I might make some mistakes in the following text.

First, to my knowledge, there is no standardized definition of using RFC 9530 digests for such a purpose. We might imagine how a server could use the Vary response header to communicate that the cache key uses Content-Digest. However, I think this might be fragile due to the nature of Content-Digest (along with vary's reuirements on request field value matching).

Second, I don't think Content-Digest would be 100% suitable because its related to the specific "bytes-on-the-wire" for the request. Two QUERY requests that are logically the same but differ by a content-coding (imagine one client can use defalte, another zstd) would evaluate to different digest values. An alternative would be https://httpwg.org/http-extensions/draft-ietf-httpbis-unencoded-digest.html

Third, the digest fields (content-digest, repr-digest, unencoded-digest) are all Structured Fields dictionaries. There are likely challenges on matching the digest algorithm choices made across clients and servers. For example, if a cache key is matching on Unencoded-Digest: sha-256=X, sha-512=Y", would it be desirable that a client can send only one value such as "Unencoded-Digest: sha-256=X" and expect to get a hit?

Cheers
Lucas
> 
> 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
> https://www.cs.ox.ac.uk/people/jesse.wright/
> https://www.linkedin.com/in/jesse-wright-49823a132/
> Book a meeting: https://cal.com/jesse-wright-zdbdal/public
> 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.*