Re: [squid-users] squid and accept-encoding gzip,deflate

On Monday 20 October 2008 10:53:14 Aviral Pandey wrote:
> My server doesn't support gzip and hence serves content in
> unzipped/raw/deflate format.
> When my client asks for Accept-Encoding: gzip, deflate, squid is sending
> it raw content. Shouldn't it gzip and then send?

No, it could (in theory) compress but it doesn't have to.

Indeed the RFCs suggest it probably shouldn't, but in reverse proxy
configuration it may make sense for something in front of the webserver to be
doing this. For most servers it is probably better to do this before the data
is sent down ANY network cable given how fast modern CPUs and buses are, and
how slow networks are.

> Is there a way in which this can be achieved?

My understanding is this is planned feature for 3mumble, there are a number of
patches that do some of it - Henrik can probably update folk on what works.

http://devel.squid-cache.org/projects.html#gzip

Neither nginx or varnish do this either I believe. Although I've seen
suggestions nginx can, so perhaps it just needs a bit of fiddling.

Apache will do this as a reverse proxy, but Apache as a reverse proxy is
interesting - most places I've seen it done it is sitting on the webserver on
port 80 forwarding to less capable webservers on another port. Although
Apache can do quite a lot as a reverse proxy the first person I saw who tried
to set it up created an open proxy - so be careful.

What webserver is it that doesn't support compression?

I looked at this somewhat, because we have an application that serves
uncompressed content which makes it slow and bandwidth hungry, but in our
case it turns out it is a bug in the specific Apache version we are using
(Debian Sarge with fastcgi) that prevents the compress filter in Apache
working as it should, so I plan just to upgrade it to something supported by
Debian security team when it will "just work" (tested already).
Received on Mon Oct 20 2008 - 10:22:05 MDT