Ao olhar para Squid3 logs, descobri que o Squid não está armazenando recursos estáticos em cache, por exemplo:
1379041607.923 611 127.0.0.1 TCP_MISS/304 356 GET http://www.deckle.co.uk/squid-users-guide/css/site.css - DIRECT/95.172.21.186 -
O pedido para esse css retorna um TCP_MISS (mesmo depois de recarregar), e o mesmo está acontecendo para imagens, javascripts, htmls, etc. De fato, quase todos os pedidos receberam TCP_MISS com a exceção de poucos .
Se olharmos para os cabeçalhos que deckle.co.uk, vemos que deve ser em cache:
$ http http://www.deckle.co.uk/squid-users-guide/css/site.css
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Encoding: gzip
Content-Length: 482
Content-Type: text/css
Date: Fri, 13 Sep 2013 03:07:09 GMT
ETag: "d6007-30e-4d2a2f615c780"
Expires: Fri, 20 Sep 2013 03:07:09 GMT
Last-Modified: Sun, 06 Jan 2013 18:34:22 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Meu arquivo de configuração contém:
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
http_access allow localhost
http_access allow all
cache_dir ufs /var/cache/squid3 10000 16 256
O que estou perdendo? Por que estou recebendo tanto TCP_MISS e o squid nem está armazenando recursos estáticos em cache?
O servidor da web remoto retornou o HTTP 304 (não modificado). Isso significa que o navegador já tinha uma cópia em cache, e o servidor instruiu o navegador a usá-lo e não enviou uma nova cópia. Portanto, não havia nada para o squid armazenar em cache.
Eu tenho o mesmo comportamento com o Squid 3.3.8 (pacote atualizado no Ubuntu 14.10 no momento da escrita)
Depois de cavar aqui , descobri que o cache mal utilizado de CSS e JS quando o Vary Header está presente foi efetivamente um bug, corrigido em versões posteriores.
Instalar o Squid 3.4.10 das fontes, faz desaparecer este problema.