When caching is enabled using mod_proxy, some clients are sending compressed content even if they do not ask (have no Accept-Encoding header) or when cached copy is compressed using a method doesn't supported by client,
Created attachment 18939 [details] fix for this bug proposed fix for this issue.
That doesn't look right to me. The proxy cache should not be in the business of checking accept-encoding unless the origin server asks it to. What should be happening here is that the origin server should be sending Vary: accept-encoding if it wants the proxy cache to check this field against the request. I have no idea if the 1.3 cache properly handles Vary. Modern versions of apache httpd (2.2) certainly do. Is the origin server in your tests sending Vary: accept-encoding?
Let split this issue on two cases: 1. Vary header in cached copy have vary: accept-encoding header and Content-encoding: gzip, while current serving reguest have only accept-encoding: compress. In this case client will get cached request with wrong (unsupported) content-encoding. 2. Yes, I see, if current request doesn't have accept-encoding header, it should not get compressed content from the cache, but in fact it does get it compressed. I have the following LogFormat defined: LogFormat "%h %l %u %t \"%r\" %>s %b \"%{User-Agent}i\" \"A-Encoding:%{Accept-Encoding}i\" \"C-Encoding:%{Content-Encoding}o\"" combinedya and this led to the following log entry occuring time to time in the log: 213.180.206.248 - - [29/Sep/2006:12:42:37 +0400] "GET /robots.txt HTTP/1.1" 200 348 "Yandex/1.01.001 (compatible; Win16; I)" "A-Encoding:-" "C-Encoding:gzip" Yandex team confirmed that it's robot got compressed content and has uproperly processed it due this issue.
The log entry doesn't prove anything. As I said, the proxy cache is not responsible for doing any content-negotiation -- it need only check for headers mentioned in the origin server's Vary response. So there are not two cases; there is only one: either the server honors the Vary header or it doesn't. You seem to be claiming that the server doesn't honor the Vary header. My quick reading of the code suggests that it should. If it doesn't, then there is indeed a bug. What version are you running exactly?
Origin server running Apache 2.0.55, while proxy running Apache 1.3.33 Those headers origin server are sending for compressed content: HTTP/1.1 200 OK Date: Sat, 30 Sep 2006 07:42:18 GMT Server: Apache/2.0.55 Set-Cookie: being=217.16.18.202.1159602138074850; path=/; expires=Wed, 24-Sep-31 07:42:18 GMT Last-Modified: Wed, 20 Sep 2006 06:53:35 GMT ETag: "50ea0e-d31-10e0f9c0" Accept-Ranges: bytes Cache-Control: max-age=3600 Expires: Sat, 30 Sep 2006 08:42:18 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 348 Connection: close Content-Type: text/plain; charset=koi8-r
all proxy and cache work in 1.3 is ended; efforts are focused on 2.2