Re: Digests, signatures and chunk extensions

[Lucas Pardue <[e-mail]>]

While MICE might require that a tree of parts constructed over a complete
resource, I'm not sure if Sam's use case requires that property. Instead a
similar but simpler "progressive integrity" content encoding (PrICE), where
the content self-describes part boundaries and their digests without
chaining, might fit the need. The benefit of including this type of thing
inside the content encoding is that it can pass across intermediaries and
HTTP versions without having to worry about re-encoding chunks or adding
new frames.

On Thu, Dec 1, 2022 at 5:08 PM Julian Reschke <[e-mail]> wrote:

> 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
>
>
>