Hi Amos, > Squid would request new data, I believe. > Any time Squid receives new files from an authoritative source it updates > its cached copy with the new content (except possibly in cases of bug #7). I am scared by the "I believe" part :). 1. Can we relay on Squid to always update its cached content if the response is newer (e.g. response has new Expires date and no other validators)? 2. Squid does not change/optimize its behavior under high load in way that could affect assumption (1)? 3. If (1) holds is this a (HTTP) standard behavior or Squid implementation? Thanks, Chris > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Thursday, October 02, 2008 4:05 AM > To: Christian Tzolov > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Can we use "no-cache" or "max-age=0" to refresh > the cached objects > > > Dear all, > > > > We have a Squid (2.6) server installed as a reverse proxy and connected > to > > an original-server that uses the "Expire" header field to specify when > the > > response should be considered stale. > > > > If the client requests includes a "no-cache" cache-control directive can > > we assume that Squid will be forced to *reload* the cached object with a > > fresh response returned by the original server (assuming that the > response > > has a new expiration date set)? > > > > The HTTP header specification > > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4) says > > that "the server MUST NOT use a cached copy when responding to such a > > request" but does not say what should happen with the current cached > > object. Would it be replaced by new response? > > > > What would be the behavior of Squid in case of "max-age=0" request > > directive (assuming again that the response has a newer expiration date > > set)? > > Squid would request new data, I believe. > Any time Squid receives new files from an authoritative source it updates > its cached copy with the new content (except possibly in cases of bug #7). > A few other things come in to play such as whether its allowed to store > the content returned, Vary, ETag etc. > > Amos This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
