- 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>
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 confusion). 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