Прокси-сервер Squid отказывается повторно проверять кеш при наличии заголовка Vary

squid.conf

cache_effective_user squid

http_access allow all

# Squid normally listens to port 3128
http_port 3128 accel defaultsite=localhost no-vhost ignore-cc

cache_peer localhost parent 80 0 no-query originserver name=myAccel
cache_peer_access myAccel allow all

# Uncomment and adjust the following to add a disk cache directory.
cache_dir ufs /usr/local/var/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /usr/local/var/cache/squid

minimum_expiry_time 0

test.php

<?php

Header( "Cache-Control: max-age=0, must-revalidate" ); 

$headers = getallheaders();
$ims = $headers['If-Modified-Since'];
$lastModified = "Mon, 16 Apr 2012 23:01:32 GMT";
if ($ims == $lastModified) {
    Header( "HTTP/1.1 304 Not Modified" ); 
    exit;
}

Header("Last-Modified: $lastModified");
if ($_GET["vary"]) Header("Vary: Accept-Encoding");

?><html>hi</html>

Squid 3.2.9, установленный на OSX через Homebrew

localhost: ~ $ squid -v
Squid Cache: Version 3.2.9
configure options:  '--disable-debug' '--disable-dependency-tracking' '--prefix=/usr/local/Cellar/squid/3.2.9' '--localstatedir=/usr/local/var' 'CC=cc' 'CXX=c++' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig'

Начат кальмар с squid -f squid.conf -d 2 -N

Когда сервер опускает заголовок «Vary: Accept-Encoding», Squid повторно проверяет / обновляет свой кеш с помощью условного GET If-Modified-Since. Но когда присутствует заголовок «Vary: Accept-Encoding», Squid отказывается использовать If-Modified-Since, а вместо этого просто игнорирует свой кеш. Зачем?

localhost: ~ $ curl --silent -o /dev/null --dump-header /dev/stdout http://localhost:3128/test.php
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2013 00:17:42 GMT
Server: Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8r
X-Powered-By: PHP/5.3.15
Cache-Control: max-age=0, must-revalidate
Last-Modified: Mon, 16 Apr 2012 23:01:32 GMT
Content-Length: 16
Content-Type: text/html
X-Cache: MISS from localhost
Via: 1.1 localhost (squid/3.2.9)
Connection: keep-alive

localhost: ~ $ curl --silent -o /dev/null --dump-header /dev/stdout http://localhost:3128/test.php
HTTP/1.1 200 OK
X-Powered-By: PHP/5.3.15
Last-Modified: Mon, 16 Apr 2012 23:01:32 GMT
Content-Length: 16
Content-Type: text/html
Date: Wed, 17 Apr 2013 00:17:43 GMT
Server: Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8r
Cache-Control: max-age=0, must-revalidate
Age: 0
X-Cache: HIT from localhost
Via: 1.1 localhost (squid/3.2.9)
Connection: keep-alive

localhost: ~ $ curl --silent -o /dev/null --dump-header /dev/stdout "http://localhost:3128/test.php?vary=1"
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2013 00:17:58 GMT
Server: Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8r
X-Powered-By: PHP/5.3.15
Cache-Control: max-age=0, must-revalidate
Last-Modified: Mon, 16 Apr 2012 23:01:32 GMT
Vary: Accept-Encoding
Content-Length: 16
Content-Type: text/html
X-Cache: MISS from localhost
Via: 1.1 localhost (squid/3.2.9)
Connection: keep-alive

localhost: ~ $ curl --silent -o /dev/null --dump-header /dev/stdout "http://localhost:3128/test.php?vary=1"
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2013 00:18:00 GMT
Server: Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8r
X-Powered-By: PHP/5.3.15
Cache-Control: max-age=0, must-revalidate
Last-Modified: Mon, 16 Apr 2012 23:01:32 GMT
Vary: Accept-Encoding
Content-Length: 16
Content-Type: text/html
X-Cache: MISS from localhost
Via: 1.1 localhost (squid/3.2.9)
Connection: keep-alive

Это действительно была ошибка, на данный момент она исправлена, подробнее о Багтрекер Squid.

Как бы то ни было, я вижу ту же проблему с версией 3.3.4, и похоже, что эта почта в squid-users описывается та же проблема с 3.2.1. Я заметил, что он, похоже, работает с 3.1.10 (который по умолчанию установлен с моим диспетчером пакетов).

Проанализировав журналы, я смог определить, что ключ поиска хэша, используемый во время хранения (то есть начальный запрос), отличается от того, который использовался во время последующих запросов. Вот почему последующие поиски - это промахи кеша.

Вооружившись этой информацией (дополнительными критериями поиска), я смог найти этот отчет об ошибке это описывает проблему. Ошибка не устранена.

Надеюсь это поможет!