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

Re: Digests, signatures and chunk extensions

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 1 Dec 2022 08:54:02 -0800
Message-Id: <BF0F11C9-7EEC-4650-96F3-2CF09F87D4AA@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Samuel Hurst <samuelh@rd.bbc.co.uk>
> On Dec 1, 2022, at 8:04 AM, Samuel Hurst <samuelh@rd.bbc.co.uk> wrote:
> 
> Hello HTTPWG,
> 
> I have a somewhat prickly question pertaining to something that I found in HTTP/1.1, around chunk extensions [1]. Specifically, where it mentions supplying per-chunk metadata "such as a signature or hash". However, upon reading the Digest [2] and Message Signatures [3] draft, they don't seem to cover specifying a chunk extension to add the hashes and signatures on a per-chunk basis. I've been doing some digging, but I've not been able to find anywhere that a chunk extension for presenting hashes and signatures for each chunk is specified, so is this somewhere else that I haven't been able to find yet?
> 
That was one of the original use cases for per-chunk metadata, but it is only usable
when both sides of the connection are expected (out of band) to do that processing.
The reason is that a general-purpose HTTP recipient will consume the chunks and
discard the metadata as a message is received, and then generate its own chunks
(if needed) when forwarding the message. Hence, the use-case only works well in
more constrained environments, like APIs and within-data-center applications, or
with long pull connections where both peers are under your control.

Personally, I wouldn't expect this to be used for streaming. It is more useful for
incremental updates of small chunks, like a chat service. Streaming clients tend
to show whatever is received first and only deal with errors in terms of reporting
for maintenance.

....Roy


Received on Thursday, 1 December 2022 16:54:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC