W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2019

Re: Digest, trailers and buffering was: Re: Updating Digest header RFC3230 using "selected representation"

From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 24 Jul 2019 13:11:39 -0700
Message-ID: <CAChr6SyGmRvSM__ZoezuVdmp=Z8=uu6tt+jedVYtVk1D4DMM6w@mail.gmail.com>
To: Roberto Polli <roberto@teamdigitale.governo.it>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 24, 2019 at 2:06 AM Roberto Polli <
roberto@teamdigitale.governo.it> wrote:

> 1- about HTTP/1.1 trailers.
> > One issue that prevented the adoption of this header and related ones
> (e.g. Content-MD5) was that
> > HTTP/1.1 trailers had a lot of interoperability problems
> > Sending the digest as a trailer reduces costs for the sender, whether
> it's an upload or download. .
> If you mean https://tools.ietf.org/html/rfc7230#section-4.4, they
> apply to transfer coded messages, so iiuc
> the only reasonable way to send Digest in a trailer was if the message
> was transfer-coded from the
> beginning by the Origin-Server. Do you agree?

Yes, I think I agree. Additionally, I wanted to point out that this did not
work very well in practice.

It seems like a trailer might work quite a bit better over HTTP/2 and later.

> 2- about huge payload

I think the key point is that you can feed bytes to a hash function
incrementally--in fact, this is the exact use case given in RFC 7230,
section 4.4. I don't think it's a security concern, but I think it would
help to point out that the sender (server or client), should probably
provide this data in a trailer (or equivalent).

Received on Wednesday, 24 July 2019 20:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:39 UTC