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

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:
     *
revise RFC 10008 to fold it in;
     *
a short companion document that formally Updates RFC 10008;
     *
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
[cid:7a9e14d9-4d29-49d4-be33-293158b49d3b]

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.

Received on Tuesday, 30 June 2026 12:58:54 UTC