[squid-users] Why does this proxy configuration ignore no-cache and no-store?

[Amos Jeffries]

On 28/09/18 11:04 AM, Brett wrote:
> I'm having some trouble because my 4.0.24-VCS squid proxy is caching requests
> that it shouldn't be, breaking the website I'm routing through it.

NP: please upgrade your proxy that is a beta release. Squid-4 now has
several stable releases.


> 
> From the HAR output of the client using the proxy:
> 
> Response Headers
> Cache-Control	
>      no-cache;no-store

Is the ';' above part of the HAR format or part of the actual headers
received?

...
> Vary	
>     Accept-Encoding
> Age	
>     24
> Warning	
>     110 squid/4.0.24-VCS "Response is stale"
> X-Cache	
>     HIT from proxy
> Via	
>     1.1 proxy (squid/4.0.24-VCS)
...

> 
> Note the no-cache;no-store Cache Control headers and then the proxy
> returning the result from the cache, and it's awareness of not following
> HTTP rules, i.e. "Response is stale"

If your response contains "Cache-Control: no-cache;no-store" then that
actually means just "Cache-Control: no-cache" which tells Squid it *can*
cache the response.

If the response contains "Cache-Control: no-cache, no-store" then that
actually means just "Cache-Control: no-store". More on that below.


> 
> This would indicate that my configuration is telling the proxy to ignore
> these rules. I do have some rules setup for images etc that do override
> cache control, but not for html, text etc, which this request was for.

One thing to be aware of "html, text etc" has no meaning to Squid. It is
working strictly from whether the given regex pattern matches against
the full URL string. Including the query-string part.

That means URLs like "http://example.com/some.html?got=.iso" will match
your pattern.


> Following is my configuration:
> 
...
> offline_mode on
...
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i \.(gif|png|jpg|jpeg|ico|woff|woff2)$ 10080 90% 43200
> override-expire ignore-no-cache ignore-no-store ignore-private
> refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90%
> 432000 override-expire ignore-no-cache ignore-no-store ignore-private
> refresh_pattern -i \.(css|js)$ 1440 40% 40320
> 

NP: ignore-no-cache is no longer supported since version ~3.2. In
HTTP/1.1 compliant proxies like Squid it actually *prevents* caching
which is counter to most intended uses and better done with
cache/store_miss/send_hit directives allow/deny rules instead.


You are also missing the default refresh_pattern line carefully crafted
to make broken CGI scripts and dynamic content behave according to
RFC2616 caching requirements. Without it such broken content will be
cached for very, very long times.

Please restore this line to the end of your refresh_pattern lines:

  refresh_pattern -i (/cgi-bin/\?) 0 0% 0


> I've also tried deleting all of the refresh_pattern statements and I still
> get the same outcome. What am I doing wrong?
> 

Three things that I can see:

1) ignore-no-store tells Squid to ignore Cache-Control:no-store headers.

Since no-store overrides no-cache in HTTP semantics which means
"Cache-Control: no-cache, no-store" is just "Cache-Control: no-store"
... you have told Squid to ignore that header entirely.

Removing that option was the right thing to do. But not sufficient by
itself (or removing the whole line ) to immediately change Squid
behaviour because of the below...


2) offline_mode on tells squid not to revalidate anything.

This directive is badly named and does not do what most people think it
does. It is global in effect. Please see the documentation:
 <http://www.squid-cache.org/Doc/config/offline_mode/>

My advice is do not use this directive unless you are in the process of
a live server migration between two proxies. In which case debugging
weird traffic behaviour is best left until the procedure is completed
and both the directive and defunct proxy removed from the traffic path.


3) override-expire with an age parameter of 43200 minutes.

The specific response you are asking about is not affected by this. But
others using Expires header will be broken in similar ways when this
setting is applied to them.


Amos