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

I'll repeat, using Content-Digest creates a class of problem that is solved
entirely by Unencoded-Digest. So if folks are going to do any
experimentation, I recommend using the appropriate tool.

On Tue, 30 Jun 2026, 18:14 Graham Cox, <graham@grahamcox.co.uk> wrote:

> At the end of the day, if the clients are generating the content digest in
> different ways it will just lead to a cache miss. That means extra server
> work and extra bandwidth, but that's exactly the case we're in today
> without this. So it basically just degrades to where we are now.
> Alternatively, if the clients generate the content digest in the same way
> and get a cache hit then that's where you get the benefits.
>
> There is a concern if two different clients somehow manage to have a
> content digest collision, but I assume that's highly unlikely. It *might*
> open up an attack vector though - a malicious client can just send queries
> with enumerated content digests to see what it gets back - but that's only
> really an issue if there's permission controls on exactly what queries can
> be executed that may not be understood by any caching layer... (Note - I do
> *not* have an Infosec background so I could easily be over/understating any
> concerns here)
>
> Cheers
> --
> Graham Cox
>
> On Tue, 30 Jun 2026 at 17:46, Rory Hewitt <rory.hewitt@gmail.com> wrote:
>
>> 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
>>
>