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

Alternatively, if the QUERY request includes *both* the request body *and*
the content-digest field, there would be more bytes over the wire than just
passing the digest field, but in terms of server *processing*, the server
could immediately check if the content-digest field exists and whether it
matches the server's saved hash of the content and return based on that? If
no match, then it can check the full request body content and return the
content from cache is there's a match. Note that this requires the server
to retain a hash of the cached content, but this isn't necessarily part of
the cache key per se - it's stored alongside the cache key

As far as Lucas's valid concerns go, there's nothing perfect about this
sort of solution - perhaps the server hash is a sha-512 and the client
sends a sha-256 content digest, perhaps the request and response differ by
encoding - but this idea seems worth pursuing.

On Tue, Jun 30, 2026 at 8:45 AM Lucas Pardue <lucas@lucaspardue.com> wrote:

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

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt