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.

Point taken.

But conceptually the format of passing a hash of the request body as a
header and having the server check that before/instead of the actual
request body is workable, from your understanding?

On Tue, Jun 30, 2026 at 11:54 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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

-- 
Rory Hewitt

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