[squid-users] TCP_REFRESH_HIT/MISS and origin servers

Hi

In a reverse proxy situation, I'm naturally trying to prevent as many
requests as possible from hitting the origin servers.

However I've run into the following situation:

1. Origin server sets 'Cache-Control: max-age=4320' (3 days) on a
fairly long-lived object
2. Squid issues TCP_HIT or TCP_MEM_HIT for 3 days - I am happy,
origin server doesn't get touched
3. After this period the object becomes stale so Squid serves up
TCP_REFRESH_HIT/200 (for normal client requests) or TCP_REFRESH_MISS/
304 (for client IMS requests)
4. Every one of these hits the origin servers, which - assuming the
object hasn't changed and isn't going to change for another 3 days -
I don't want

There appears to be no out-of-the-box way of getting Squid to carry
on caching an unchanged object beyond the max-age/expiry values
contained in the initial fetch from the origin server.

Unless I've missed something, it seems the only ways to get Squid to
"carry on" caching such an object are either (a) to modify it on the
origin server (causing a TCP_REFRESH_MISS/200) or (b) to purge it
from cache altogether. This process would have to be repeated
whenever the object became stale again.

I'm not sure if my analysis is correct, but is there some reason why
a TCP_REFRESH_HIT or TCP_REFRESH_MISS (i.e. a 304 Not Modified from
an origin server for a stale object) would not cause Squid to update
its store entry with any new max-age/expires values supplied with the
origin server's 304 response?

In other words, could a 304 Not Modified issued by an origin server
be used to extend the cache lifetime of the object to which it
refers? This seems to be the best way of telling Squid that it should
treat the object as fresh again.

Thanks for your wisdom

Doug
Received on Mon Feb 13 2006 - 19:55:01 MST