Re: improved caching in HTTP: new draft

Am 27.05.2014 12:46, schrieb Poul-Henning Kamp:
> 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...

No, I'm not surprised. The SHA256 value can be computed when the 
document is made available on the server or when the document changes 
(like it is compressed and stored before any client requests it). So 
there is no need for computing it again for every single request.

For the cache system it is different. I suggest to store an incoming 
response with a Cache-NT header field. During low load the cache system 
can compute the SHA256 value and validate it with the hash value in the 
response message. If both are equal then the cache system can reuse the 
cache item for subsequent requests.

Received on Wednesday, 28 May 2014 10:40:55 UTC