Re: An HTTP digest for PATCHing?

PATCH suggests that the If-match with strong ETag fits a similar purpose for "pre". I'd be wary of trying to define an extension that overlaps too much with that .

On Mon, May 11, 2026, at 21:10, Rory Hewitt wrote:
> 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