Bug 40646 - proxy cache not honoring vary header
Summary: proxy cache not honoring vary header
Alias: None
Product: Apache httpd-1.3
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 1.3.33
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2006-09-29 12:39 UTC by Maxim Zakharov
Modified: 2007-08-02 13:14 UTC (History)
0 users

fix for this bug (779 bytes, patch)
2006-09-29 12:44 UTC, Maxim Zakharov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Zakharov 2006-09-29 12:39:34 UTC
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,
Comment 1 Maxim Zakharov 2006-09-29 12:44:50 UTC
Created attachment 18939 [details]
fix for this bug

proposed fix for this issue.
Comment 2 Joshua Slive 2006-09-29 14:43:34 UTC
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?
Comment 3 Maxim Zakharov 2006-09-29 16:02:34 UTC
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)

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: - - [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.
Comment 4 Joshua Slive 2006-09-29 18:42:37 UTC
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?
Comment 5 Maxim Zakharov 2006-09-30 01:13:41 UTC
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=; 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
Comment 6 Jim Jagielski 2007-08-02 13:14:05 UTC
all proxy and cache work in 1.3 is ended; efforts are focused on 2.2