[squid-users] Accept-encoding and error_map responses

From: Michael Alger <[email protected]>
Date: Fri, 12 Oct 2007 01:28:47 -0400

I'm using error_map to replace server-side errors with a nicer page
in a reverse proxy setup (2.6.5-6 from Debian etch):

error_map http://errors.local:2080/ErrorPage/401.html 401
error_map http://errors.local:2080/ErrorPage/403.html 403
error_map http://errors.local:2080/ErrorPage/500.html 500
error_map http://errors.local:2080/ErrorPage/503.html 503

errors.local resolves to a loopback address, and I have thttpd listening
on port 2080 to serve these pages.

The problem I have is that sometimes the "500" response error page is
completely blank. A capture using Wireshark reveals that squid's
response says Content-Encoding: gzip, but the content it returns isn't
compressed.

As an experiment, I gzipped the 500.html page and it did in fact display
correctly. However, that's obviously not a very good workaround because
it will result in gzipped responses to clients which haven't indicated
that they can accept such things.

What I think is happening is that the origin server's 500 response is
gzipped, and it sets the Content-Encoding header appropriately. squid
sees the 500 response, and requests the "500.html" replacement page from
the local server. However, it retains the Content-Encoding header from
the origin's response, despite the fact that the new page isn't
compressed.

I created a 500.cgi as a simple shell script to output all environment
variables. It appears there isn't any HTTP_ACCEPT_ENCODING variable
being set. I was intending to use this to have the script decide whether
to send a gzipped version or not, but it appears it's not given that
information about the original request. A quick test I did bypassing
does result in HTTP_ACCEPT_ENCODING being set, so I think squid is
simply not passing on the Accept-Encoding value from the original
request when it requests the error_map'd replacement. It does appear to
pass on cookies and Accept: values. Is this a bug?

Has anybody else encountered this? Is there a way to get this to work
reliably with compression?
Received on Thu Oct 11 2007 - 23:28:49 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Nov 01 2007 - 13:00:01 MDT