[squid-users] 2.7.9 to 3.5 CentOS No-Cache

[Amos Jeffries]

On 13/02/2015 1:24 p.m., Tory M Blue wrote:
> Greetings all, been a bit.
> 
> So I'm working on a new server config and loaded the latest 3.5 and have
> tweaked my 2.7 configs a bit. Things are working but I've got one that I
> can't figure out.
> 
> I have a test that insures that objects with an explicit "
> Cache-Control: no-cache" header are NOT cached by Squid.

Your test is wrong. What the HTTP/1.1 specification says about no-cache
is that it has three forms of behaviour:

 1) when Cache-Control:no-cache is sent by a client it means do not
deliver cached contect in the response.

 2) when Cache-Control:no-cache is sent by the server it means the
content *can* be cached but must be revalidated before each use.
 - its effectively an alias for Cache-Control:must-revalidate

 3) when Cache-Control:no-cache="Hello" is sent by the server it means
the header "Hello: ..." must not be delivered on HIT responses, if
possible a revalidation should take place.



PS. since you are testing HTTP behaviour you may also need to be aware
that authenticated and Cache-Control:private="Set-Cookie" responses have
similar cacheability in HTTP/1.1.
 Responses with confidential data *can* be cached if it also contains
controls to ensure the origin server has explicit involvement in each
HIT determination.


> This is done by
> keeping a special hit counter on the server and counting origin requests. A
> unique URL is fetched exactly 10 times, and all of them are asserted to be
> cache misses (both Squid headers must be MISS). At the end, the hit counter
> is tested and made sure it equals the number of requests (10)."
> 
> I'm getting a fail when testing against 3.5, meaning it's providing a cache
> object
> 
> Miss with no-cache                  | FAIL    <------
> 
> 
> Running test: Miss with no-cache...
> Resetting hit counter...
> Fetching URL:
> http://10.13.5.222/admin/squid_test.php?action=reset_hit_count&random=0.385536803712753
> HTTP 200: 200 OK
> X-Cache: MISS from dev-centOS
> X-Cache-Lookup: MISS from dev-centOS:80
> Fetching URL:
> http://10.13.5.222/admin/squid_test.php?action=simple&type=no_cache&random=0.0843643311677589
> HTTP 200: 200 OK
> X-Cache: MISS from dev-centOS
> X-Cache-Lookup: MISS from dev-centOS:80
> Fetching URL:
> http://10.13.5.222/admin/squid_test.php?action=simple&type=no_cache&random=0.0843643311677589
> HTTP 200: 200 OK
> X-Cache: MISS from dev-centOS
> X-Cache-Lookup: HIT from dev-centOS:80 *<—— Shows a hit (this should be 10
> misses , a hit should never happen)*

... those headers lie sometimes with HTTP/1.1. That in particular is a
REFRESH (near-HIT), not a full HIT.

> 
> *Test fails*
> 


Your test should probably be passing anyway. The server should still be
counting the refresh queries and get to 10. Checking for the value of
the Squid headers is the problem.

A small update to your test so that the server sends back its counter in
a custom header for each response would be a better verification of
correctness and should pass.


> w/ 2.7.9 config
> Miss with no-cache                  | Pass
> 
> Running test: Miss with no-cache...
> Resetting hit counter...
> Fetching URL:
> http://devcache01.eng.admission.net/admin/squid_test.php?action=reset_hit_count&random=0.671442807268036
> HTTP 200: 200 OK
> X-Cache: MISS from dev-cache
> X-Cache-Lookup: MISS from dev-cache:80
> 
> *I get 10 of the above responses (test passes).*
> 
> I'm wondering what I'm missing, 3.5 should be fully http 1.1 compliant
> meaning that there should not be any squid directives guiding this (nor can
> I find any). If the client sends a "Cache-Control: no-cache" it should be
> honored natively ya?

It is HTTP/1.1 software and implements the Cache-Control:no-cache
feature closely according to RFC.


Squid-2.7 is HTTP/1.0 software which does not implement the HTTP/1.1
Cache-Control:no-cache feature (or many others either).

Instead it contains a custom hack that treats Cache-Control:no-cache as
if it were Cache-Control:no-store because that is the closest safe
mapping into HTTP/1.0 behaviour where revalidation does not exist.

Amos