W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: HTTP Instance Digests and encoding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 21 May 2018 13:48:59 +0200
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <1446d724-fb27-282c-355f-3b712a0f2a06@gmx.de>
On 2018-05-21 11:46, Lucas Pardue wrote:
> Hi Amos,
> Thanks for the response! This clarifies things for me.
>> Each of your objects has two digests to compute. Just like it has two
>> deliverable variants for each resource; C-E:gzip and C-E:identity (aka no C-E).
>> If you want to use gzip as instance manipulation that makes it Transfer-
>> Encoding, *not* Content-Encoding.
> To ask a simple question using an example, is the following behaviour valid?
> 1) An origin server is configured to serve the file example.txt with either C-E:identity or C-E:gzip.
> 2) Client requests example.txt with Accept-Encoding: gzip request header.
> 3) Server performs "on-demand" gzip compression, server calculates an instance digest on the results. Server may cache the result of this operation (implementation and configuration dependent).
> 4) Server adds Content-Encoding and Digest response headers.
> Kind regards
> Lucas

AFAIR, there were arguments about whether RFC 3230 actually got the 
terminology right (it tries to clarify RFC 2616 but IMHO added even more 

If you are serious about this, you may want to update RFC 3230 based on 
the terminology in RFC 723*.

Best regards, Julian
Received on Monday, 21 May 2018 11:49:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC