Re: An HTTP digest for PATCHing?

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 PM 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 understanding
> 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, performs
> 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 you
> 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
>
>
>

-- 
Rory Hewitt

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