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