Re: Problem with squid interpretting gzipped content from Apache

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 18 Apr 2013 01:39:10 +1200

On 18/04/2013 1:00 a.m., babajaga wrote:
> Hi,
>
> is it possible to re-organize all the posts regarding this topic ?
> I am asking, because of special interest, and the posts regarding this issue
> are spread all over different threads, unfortunately.

Possibly. Although I'm not game enough to edit the headers of each
thread message to link them.

> Now my few bits: When squid caches up to several versions of the same URL,
> depending on encoding (gzip, deflate, etc.) then the question arises: Is'nt
> it reasonable to store just one variant (unencoded OR gzip), and do a
> conversion on-the-fly, in case another version requested ?
Not all encodings are translatable. For example sdch used by Chrome is
highly compact but is effectively a diff patch against the client cached
object.

Then again encoding is only one header. Any header the server wishes to
look at can be listed in Vary:, catering for all of them in every
potential permutation is a huge consumer of CPU cycles as Anita is about
to find out when this prefetcher hits normal traffic.

> Would not only help the prefetching, but for actual use, as well, to save
> some cache space.
> Or am I wrong here ?

Squid is slow enough as it is without adding this to the processing
overheads. We trade plentiful disk space for scarce CPU cycles.

There is a Key: header being proposed to extend Vary: header in a few
nice ways which enable more efficient caching of variants.
http://tools.ietf.org/html/draft-fielding-http-key-02

Amos
Received on Wed Apr 17 2013 - 13:39:16 MDT

This archive was generated by hypermail 2.2.0 : Thu Apr 18 2013 - 12:00:06 MDT