Search squid archive

TCP_REFRESH_HIT/MISS and origin servers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux