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?
