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

Re: improved caching in HTTP: new draft

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 27 May 2014 10:46:49 +0000
To: Chris Drechsler <chris.drechsler@etit.tu-chemnitz.de>
cc: ietf-http-wg@w3.org
Message-ID: <51364.1401187609@critter.freebsd.dk>
In message <53846489.9010905@etit.tu-chemnitz.de>, Chris Drechsler writes:
>Am 23.05.2014 16:20, schrieb Poul-Henning Kamp:

>> Although I have yet to see any non-contrived examples, there is
>> absolutely nothing preventing the exact same body from having
>> two entirely different meanings, depending on the headers.
>> For instance:
>> 	Content-Encoding: gzip
>> 	Content-Type: text/html
>> 	<gzip'ed body>
>> vs.
>> 	Content-Type: application/x-gzip
>> 	<exact same gzip'ed body>
>> Are two very different responses for any sensible client, yet your
>> proposal would deliver either one for the other.
>In the first case the input is for example an html document and the 
>server computes the SHA256 value before the document is compressed 
>In the second case the input is an already compressed file, e.g. 
>foo.html.gz. It will not be compressed again by the server during the 
>process of sending (no Content-Encoding is applied). The SHA256 value is 
>different to the former case:

Would you be surprised if I tell you that most high-performance
servers and caches try their damnest to avoid running a gzip
compressor during delivery ?

In the first case the server would often have to run a gzip
decompressor to calculate the SHA256...

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 27 May 2014 10:47:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC