Re: [squid-users] squid and accept-encoding gzip,deflate
Aviral Pandey wrote: Thanks Henrik...But I have seen vice-versa to be working i.e., server sending a gzipped response and squid serving deflated one when client asks for deflated content Are you sure? squid does _transfer_ chunked decoding. But thats special compression only 'zipped' between the web server and Squid (and web server is broken to be trying it with Squid anyway). ...or perhapse you have a version of that gzip patch applied. It's not new. ... or maybe you hit the Vary: bug where squid always presented the deflate copy no matter what once it received the first deflate copy. :( Amos My squid is 2.6-16. Thanks, Avi http://aviral.piworx.com Henrik Nordstrom wrote: On mån, 2008-10-20 at 15:23 +0530, Aviral Pandey wrote: When my client asks for Accept-Encoding: gzip, deflate, squid is sending it raw content. Shouldn't it gzip and then send? No, Content-Encoding (just as Content-Languate) is a task of webservers, not semantically transparent proxies such as Squid. Is there a way in which this can be achieved? There is an addon for squid-3, but it apparently needs a bit of work to apply to current Squid-3 sources. Regards Henrik -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [squid-users] squid and accept-encoding gzip,deflate
On mån, 2008-10-20 at 11:21 +0100, Simon Waters wrote: > 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. Also mod_deflate still works very sub-otimal when it comes to HTTP & caching. Currently cache validations is a bit broken, after it was fixed to at least minimally comply with HTTP specifications. There is an open task in the Apache project for supporting mod_deflate and similar filters that conditionally modify the response entity and thereby creating new variants of the requested resource. HTTP isn't really designed for this and getting it right requires some care.. (ETag needs to be remapped, in a way that If-* conditional requests still to the right thing). Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] squid and accept-encoding gzip,deflate
What webserver is it that doesn't support compression? Its a custom webserver, a very simple one which does file serving and has no application built upon it. I am using squid as a reverse proxy here.
Re: [squid-users] squid and accept-encoding gzip,deflate
On mån, 2008-10-20 at 16:08 +0530, Aviral Pandey wrote: > Thanks Henrik...But I have seen vice-versa to be working i.e., server > sending a gzipped response and squid serving deflated one when client > asks for deflated content This is not available in any Squid version. But Squid do support servers doing this correctly, by caching both gzip:ed and plain variants of the resource. All servers I know of supporting gzip also supports serving plain variants when the client do not support gzip. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] squid and accept-encoding gzip,deflate
Thanks Henrik...But I have seen vice-versa to be working i.e., server sending a gzipped response and squid serving deflated one when client asks for deflated content My squid is 2.6-16. Thanks, Avi http://aviral.piworx.com Henrik Nordstrom wrote: On mån, 2008-10-20 at 15:23 +0530, Aviral Pandey wrote: When my client asks for Accept-Encoding: gzip, deflate, squid is sending it raw content. Shouldn't it gzip and then send? No, Content-Encoding (just as Content-Languate) is a task of webservers, not semantically transparent proxies such as Squid. Is there a way in which this can be achieved? There is an addon for squid-3, but it apparently needs a bit of work to apply to current Squid-3 sources. Regards Henrik
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).
Re: [squid-users] squid and accept-encoding gzip,deflate
On mån, 2008-10-20 at 15:23 +0530, Aviral Pandey wrote: > When my client asks for Accept-Encoding: gzip, deflate, squid is sending > it raw content. Shouldn't it gzip and then send? No, Content-Encoding (just as Content-Languate) is a task of webservers, not semantically transparent proxies such as Squid. > Is there a way in which > this can be achieved? There is an addon for squid-3, but it apparently needs a bit of work to apply to current Squid-3 sources. Regards Henrik signature.asc Description: This is a digitally signed message part
[squid-users] squid and accept-encoding gzip,deflate
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? Is there a way in which this can be achieved? Thanks, Avi
