Re: [squid-users] Directives ignore-private and override-expire not working Squid 3.2 and 3.3

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 26 Nov 2013 20:14:40 +1300

On 26/11/2013 6:06 p.m., Le Trung, Kien wrote:
> Hi, Eliezer Croitoru
>
> I already sent the header in the first email. Is this the information you want ?
> ========= Squid 3.3.x ============
> HTTP/1.1 200 OK
> Cache-Control: private
> Content-Length: 117991
> Content-Type: text/html; charset=utf-8
> Expires: Thu, 21 Nov 2013 03:12:14 GMT
> Server: Microsoft-IIS/7.5
> Date: Thu, 21 Nov 2013 03:12:15 GMT
> X-Cache: MISS from localhost.localdomain
> Connection: close
>
> And after Amos's reply I check again the header of Squid-3.1
>
> ========= Squid 3.1.x ============
> HTTP/1.0 200 OK
> Cache-Control: private
> Content-Type: text/html; charset=utf-8
> Expires: Tue, 26 Nov 2013 05:00:03 GMT
> Server: Microsoft-IIS/7.5
> Date: Tue, 26 Nov 2013 05:00:04 GMT
> Content-Length: 117904
> Age: 64
> Warning: 110 squid/3.1.23 "Response is stale" (confused here too !)
> X-Cache: HIT from localhost.localdomain
> Connection: close
>
> In both case I used the same directives ignore-private and
> override-expire and same origin server. Squids also built in same
> server, the difference is only http service ports.
>
> Still don't know why squid 3.3 and 3.2 can't ignore-private and
> override-expire header.

I still think you are misunderstanding what is happening here.

Ignoring "private" simply means that Squid will store it instead of
discarding immediately as required by RFC 2616 (and by Law in many
countries). For safe use of privileged information we consider this
content to expire the instant it was received.
 * The handling of that content once it is in cache still goes ahead in
full accordance with HTTP/1.1 requirements had the private not been
there to prevent caching.

"override-expires" means that when the Expires: header is present the
value inside it is replaced (overridden with) with the values in
refresh_pattern header.
 * The calculation of how fresh/stale the object is still happens - just
without the HTTP response header value for Expires.

3.1.20 are HTTP/1.0 proxies and do not perform HTTP/1.1 protocol
validation perfectly. The headers still contain the Squid Warning: about
the object coming out of cache (HIT) and being stale.

3.2+ are HTTP/1.1 proxies and are more strictly following RFC2616
requirements about revalidating stale content before use. It just
happened that the server presented a new copy for delivery.

NOTE: private *was* ignored. Expires *was* overridden. There was new
content to deliver regardless of the values you changed them to.

ALSO NOTE: The X-Cache header does not display REFRESH states. It
displays "MISS" usually in the event of REFRESH_MODIFIED and "HIT"
usually in the event of REFRESH_UNMODIFIED.

You can get a better test of the private/Expires caching by causing the
server those objects came from to be disconnected/unavailable when
accessed from your Squid. In which case you should see the same headers
as present in 3.1 indicating a HIT with stale object returned.

Amos
Received on Tue Nov 26 2013 - 07:15:12 MST

This archive was generated by hypermail 2.2.0 : Tue Nov 26 2013 - 12:00:05 MST