Re: An HTTP digest for PATCHing?

On Mon, May 11, 2026, at 21:42, Rory Hewitt wrote:
> Yeah, I agree. Although ETags, like CORS, are not documented well. Additionally, does ETag work as well for server-push content?

At this stage in my life, I choose to think sever-push doesn't exist :-)

I'm not not an ETag expert and would probably stick my words with "you can but its an exercise for reader "
> 
> You could simply have a Content-Post-Hash or similarly-named header, but it would be nice to have a standard naming...
As Roberto alluded to, this sounds like a variant of the unencoded-digest header. That I-D has received IESG reviews, got a few minor things to iron out and is needed for a concrete use case. There's good reason to let it progress on ahead.

Do folks think there's any value in a 00 I-D of bikeshed-unencoded-digest at least as a strawperson?

Cheers
Lucas
> 
> On Mon, May 11, 2026 at 1:26 PM Lucas Pardue <lucas@lucaspardue.com> wrote:
>> __
>> 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
>> 
> 
> 
> --
> Rory Hewitt
> 
> https://www.linkedin.com/in/roryhewitt