Re: Mahesh Jethanandani's Discuss on draft-ietf-httpbis-unencoded-digest-04: (with DISCUSS and COMMENT)

Hi Mahesh,

On Mon, Mar 30, 2026, at 20:40, Mahesh Jethanandani wrote:
> Hi Lucas,
> 
> Thanks for your responses.
> 
> Pruning the list down to what is still outstanding.
> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Section 1, paragraph 5
>>> >    For a variety of reasons, decoding and re-encoding content in order
>>> >    to benefit from HTTP integrity fields is not preferable.  This
>>> >    specification defines the Unencoded-Digest and Want-Unencoded-Digest
>>> >    fields to support a simpler validation workflow in some scenarios
>>> >    where content coding is applied.  These fields complement the other
>>> >    integrity fields defined in [DIGEST-FIELDS].
>>> 
>>> There is an implicit assumption that this draft does not state explicitly, i.e.,
>>> the server must know the digest of the complete unencoded resource before it
>>> sends the first chunk. That means:
>>> 
>>> - The server cannot compute Unencoded-Digest on-the-fly as it streams/encodes
>>> data. - It must either have pre-computed the digest and stored it, or buffer
>>> the entire unencoded content first, hash it, then start sending.
>>> 
>>> This is actually a non-trivial constraint that the draft glosses over.
>>> RFC 9530 discusses the streaming vs. pre-computation trade-off for Repr-Digest
>>> in Section 6.1 ("Digest and Content-Encoding"), but this document just says
>>> Unencoded-Digest "behaves similarly to Repr-Digest" and leaves it at that.
>>> 
>>> This draft should explicitly note that Unencoded-Digest cannot be computed
>>> lazily during transmission, and requires the server to have prior knowledge
>>> of the digest of the complete unencoded representation — either from storage
>>> or pre-computation. This is a meaningful deployment consideration for servers
>>> handling large objects or dynamically generated content, and it belongs to
>>> either in Section 3 or Section 5.
>> 
>> I disagree with this assessment. A server sending a representation with no content coding can calculate the Unencoded-Digest on the fly and send it in a trailers if it so wishes. Section 3 makes it clear the field is allowed in trailers, as required to be stated by Section 16.3.2 of RFC 9110.
> 
> Thanks for the explanation. But that explanation is not apparent reading Section 3 or looking at the examples in Section 5. Maybe expanding that sentence would help.

Implementing HTTP Digests requires a full understanding of HTTP semantics. How an endpoint calculates the digest value it sends its peer is mostly an implementation detail. 

The present text addresses the interoperability requirements of the protocol
I don't think adding more text around this particular topic will help. In fact, I think it would risk distracting or confusing readers because there's nothing really special about it in the context of HTTP. Even more so because RFC 9530 doesn't pay special attention to it.


> 
>> 
>> I'm not sure what part of RFC 9530 you're referring to. Section 6.1 of RFC 9530 is titled "HTTP Messages Are Not Protected in Full". The whole of RFC 9530 has a pretty light touch wrt trailers, and the unencoded-digest draft has a similar amount.
>>> 
>>> Section 4, paragraph 5
>>> >    *  value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that
>>> >       conveys an ascending, relative, weighted preference.  It must be
>>> >       in the range 0 to 10 inclusive. 1 is the least preferred, 10 is
>>> >       the most preferred, and a value of 0 means "not acceptable".
>>> 
>>> This section uses lowercase "must," leaving the normative force ambiguous. RFC
>>> 9530 Section 4 uses the same lowercase "must" for Want-Repr-Digest, so this is
>>> consistent with the parent document. Nevertheless, if senders generating
>>> out-of-range values would cause interoperability failures, this should be
>>> "MUST". A brief clarifying note (e.g., whether the Structured Fields Integer
>>> type already enforces this, which would make the normative level moot) would
>>> help.
>> Structured Fields has no opinion on the rules applied on top of its own. I think maintaining consistency with RFC 9530 is the important thing to do here.
> 
> In that case, the second suggestion (of a clarifying note) would be helpful to add.
> 
> These are non-blocking comments at the end of the day. Therefore, it is up to you to incorporate them or ignore them.

Noted, thanks

Cheers
Lucas
> 
> Cheers.
> 
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 
> 
> 
>