By looking to Squid3
logs, I've found that Squid it's not caching static resources, for example:
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 -
The request for that css returns a TCP_MISS
(even after reloading), and the same is happening for images, javascripts, htmls, etc. In fact, almost all requests got TCP_MISS
with the exception of a very few.
If we look at the headers that deckle.co.uk, we see that it should be caching it:
$ 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
My config file contains:
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
What am I missing? Why am I getting so much TCP_MISS
and squid is not even caching static resources?
The remote web server returned HTTP 304 (Not Modified). This means the browser already had a cached copy, and the server instructed the browser to use it, and didn't send a new copy. Therefore there was nothing for squid to cache.
I got the same behaviour with Squid 3.3.8 (package up to date on Ubuntu 14.10 at the time of writing)
After digging here, I found out that the cache mishandling of CSS and JS when the Vary Header is present was effectively a bug, fixed in posterious releases.
Installing Squid 3.4.10 from the sources, makes disapear this issue.