W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: Digests, signatures and chunk extensions

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 1 Dec 2022 18:07:21 +0100
Message-ID: <668733a2-6249-5c7a-1d91-7820cd9d58d6@gmx.de>
To: ietf-http-wg@w3.org
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
Received on Thursday, 1 December 2022 17:07:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC