Resent-Date: Mon, 11 May 2026 20:11:14 +0000
Resent-Message-Id: <E1wMWyA-002T0e-1C@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::636 as permitted sender) client-ip=2a00:1450:4864:20::636; envelope-from=roryhewitt@gmail.com; helo=mail-ej1-x636.google.com;
MIME-Version: 1.0
References: <83736c89-5d58-4965-a16e-13d5c40a567b@app.fastmail.com>
In-Reply-To: <83736c89-5d58-4965-a16e-13d5c40a567b@app.fastmail.com>
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Mon, 11 May 2026 13:10:53 -0700
Message-ID: <CAEmMwDxsxYnuVqQ_NZoW0kjBMLOp=uWyKcJu_Y_On1gL9Z7pKw@mail.gmail.com>
To: Lucas Pardue <lucas@lucaspardue.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000009c5e8d065190582c"
Subject: Re: An HTTP digest for PATCHing?
Archived-At: <https://www.w3.org/mid/CAEmMwDxsxYnuVqQ_NZoW0kjBMLOp=uWyKcJu_Y_On1gL9Z7pKw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--0000000000009c5e8d065190582c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FWIW, this seems like it could/should be generalized to other
non-idempotent P-cases (PUT/POST/PATCH) - some standard request parameter
which either a client or server can pass to indicate to the receiving
server/client that, following processing, certain things must be true.

The primary use-case would be a hash of the result of the operation, but
could there be a situation - perhaps with a frequently/quickly-updated
object - where a client needs to indicate to a server that object O must be
updated, but only if the current hash is XXXX...XXXX *and* following the
processing, the hash must be YYYY...YYYY?

Perhaps two optional headers - simplistically something like:

*{hash-header}: "{algo};{hash}"*

For example:

Content-Pre-Hash: "sha256; xxxx...xxxx"
Content-Post-Hash: "md5; yyyy...yyyy"

Or maybe this all exists already, in some form or another?

Rory


On Sun, May 10, 2026 at 8:17=E2=80=AFPM Lucas Pardue <lucas@lucaspardue.com=
> wrote:

> Hi digest enthusiasts!
>
> As part of some discussion in one of the resumable uploads issues, we
> stumbled upon a bit of and edge case that I forgot about since it was
> tangential to the primary issue. I'll attempt to summarise my understandi=
ng
> in an example scenario.
>
> Imagine there's an existing resource of X bytes, with a client wishing to
> use PATCH to append Y bytes to it. The server accepts the request, perfor=
ms
> the patch, and the resource is now X+Y bytes.
>
> The client initiating the request can indicate the digest(s) of the patch
> document: content, repr, or identity. The server can indicate the
> digests(s) related to the resource and/or transfers related to it. This
> could be prior to or after patching. (ETags also play a role, if aspects =
of
> RFC 5789 are in play [1]).
>
> However, there's no digesty way for a client to articulate what it might
> expect the outcome of the patch to be. In other words, it can't say "If y=
ou
> apply patch document with bytes Y the hash of X+Y is foo. If it's not foo=
,
> the operation failed". This seems very niche and I don't have a personal
> use case. So throwing it out to the list in case there's other opinions.
>
> Cheers,
> Lucas
>
> [1] https://httpwg.org/specs/rfc5789.html#rfc.section.2
>
>
>

--=20
Rory Hewitt

https://www.linkedin.com/in/roryhewitt

--0000000000009c5e8d065190582c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif;color:#3333ff">FWIW, this seems like it could/should be generali=
zed to other non-idempotent P-cases (PUT/POST/PATCH) - some standard reques=
t parameter which either a client or server can pass to indicate to the rec=
eiving server/client that, following processing, certain things must be tru=
e.</div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-seri=
f;color:#3333ff"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:verdana,sans-serif;color:#3333ff">The primary use-case would be a hash of=
 the result of the operation, but could there be a situation - perhaps with=
 a frequently/quickly-updated object - where a client needs to indicate to =
a server that object O must be updated, but only if the current hash is XXX=
X...XXXX=C2=A0<u>and</u>=C2=A0following the processing, the hash must be YY=
YY...YYYY?<br></div><div class=3D"gmail_default" style=3D"font-family:verda=
na,sans-serif;color:#3333ff"><br></div><div class=3D"gmail_default" style=
=3D"font-family:verdana,sans-serif;color:#3333ff">Perhaps two optional head=
ers - simplistically something like:</div><div class=3D"gmail_default" styl=
e=3D"font-family:verdana,sans-serif;color:#3333ff"><br></div><div class=3D"=
gmail_default" style=3D"font-family:verdana,sans-serif;color:#3333ff"><b>{h=
ash-header}: &quot;{algo};{hash}&quot;</b></div><div class=3D"gmail_default=
" style=3D"font-family:verdana,sans-serif;color:#3333ff"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:#3333ff"=
>For example:</div><div class=3D"gmail_default" style=3D"font-family:verdan=
a,sans-serif;color:#3333ff"><br></div><div class=3D"gmail_default" style=3D=
"font-family:verdana,sans-serif;color:#3333ff">Content-Pre-Hash: &quot;sha2=
56; xxxx...xxxx&quot;</div><div class=3D"gmail_default" style=3D"font-famil=
y:verdana,sans-serif;color:#3333ff">Content-Post-Hash: &quot;md5; yyyy...yy=
yy&quot;</div><div class=3D"gmail_default" style=3D"font-family:verdana,san=
s-serif;color:#3333ff"><br></div><div class=3D"gmail_default" style=3D"font=
-family:verdana,sans-serif;color:#3333ff">Or maybe this all exists already,=
 in some form or another?</div><div class=3D"gmail_default" style=3D"font-f=
amily:verdana,sans-serif;color:#3333ff"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:verdana,sans-serif;color:#3333ff">Rory</div><div c=
lass=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:#3333f=
f"><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Sun, May 10, 2026 at 8:17=E2=80=AFPM =
Lucas Pardue &lt;<a href=3D"mailto:lucas@lucaspardue.com">lucas@lucaspardue=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><u></u><div><div>Hi digest enthusiasts!</div><div><br></div><div>As par=
t of some discussion in one of the resumable uploads issues, we stumbled up=
on a bit of and edge case that I forgot about since it was tangential to th=
e primary issue. I&#39;ll attempt to summarise my understanding in an examp=
le scenario.</div><div><br></div><div>Imagine there&#39;s an existing resou=
rce of X bytes, with a client wishing to use PATCH to append Y bytes to it.=
 The server accepts the request, performs the patch, and the resource is no=
w X+Y bytes.</div><div><br></div><div><div>The client initiating the reques=
t can indicate the digest(s) of the patch document: content, repr, or ident=
ity. The server can indicate the digests(s) related to the resource and/or =
transfers related to it. This could be prior to or after patching. (ETags a=
lso play a role, if aspects of RFC 5789 are in play [1]). </div><div><br></=
div><div>However, there&#39;s no digesty way for a client to articulate wha=
t it might expect the outcome of the patch to be. In other words, it can=
9;t say &quot;If you apply patch document with bytes Y the hash of X+Y is f=
oo. If it&#39;s not foo, the operation failed&quot;. This seems very niche =
and I don&#39;t have a personal use case. So throwing it out to the list in=
 case there&#39;s other opinions.</div><div><br></div><div>Cheers,</div><di=
v>Lucas</div><div><br></div><div>[1]=C2=A0<a href=3D"https://httpwg.org/spe=
cs/rfc5789.html#rfc.section.2" target=3D"_blank">https://httpwg.org/specs/r=
fc5789.html#rfc.section.2</a></div><br></div><div><br></div></div></blockqu=
ote></div><div><br clear=3D"all"></div><div><br></div><span class=3D"gmail_=
signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">=
<div dir=3D"ltr"><div><div dir=3D"ltr"><div><span style=3D"font-family:verd=
ana,sans-serif;color:rgb(51,51,255)">Rory Hewitt</span><br style=3D"font-fa=
mily:verdana,sans-serif;color:rgb(51,51,255)"><br style=3D"font-family:verd=
ana,sans-serif;color:rgb(51,51,255)"><span style=3D"font-family:verdana,san=
s-serif;color:rgb(51,51,255)"><a href=3D"https://www.linkedin.com/in/roryhe=
witt" target=3D"_blank">https://www.linkedin.com/in/roryhewitt</a></span><b=
r></div></div></div></div></div>

--0000000000009c5e8d065190582c--