Re: Digests, signatures and chunk extensions

[Julian Reschke <[e-mail]>]

On 01.12.2022 17:55, Ilari Liusvaara wrote:
> On Thu, Dec 01, 2022 at 04:30:18PM +0000, Samuel Hurst wrote:
>> Hi Lucas,
>>
>> On 01/12/2022 16:20, Lucas Pardue wrote:
>>> Hiya Sam,
>>>
>>> This sounds like something that the MICE (Merkle Integrity Content
>>> Encoding( draft [1] might help you solve?
>>>
>>> Cheers,
>>> Lucas
>>>
>>> [1] - https://datatracker.ietf.org/doc/draft-thomson-http-mice/
>>
>> Thanks for the quick response. At first glance, this looks like it
>> could be what I'm after. Any pointers towards any implementations
>> would be very gratefully received!
>
> Looking at the draft, I do not think it fits your usecase. Specifically,
> it seemingly requires the entiere rest of response to be available to
> even start sending, which is obviously not going to work for live
> streaming.
>
> And with regards to chunk extensions, use of those is essentially
> unspecified, and virtually all implementations just ignore those.

You make it sound as if Martin's content coding uses chunk extensions -
that is not the case.

> Nominally, HTTP/2 has middlers (HEADERS that is not End of Stream
> after initial request/final response) where one could stuff weird
> out-of-band metadata, but sending those will probably make a lot of
> implementations to either puke or become very confused.
> I do not know if HTTP/3 can send middlers.
>
> Obviously, none of this will work through any forward or reverse
> proxies.

When we worked on RFC 9110, we tried to define the generic concept of
middlers (for use in H/3), but were told to back them out :-(.

Best regards, Julian