Thanks Amos, Detailed explanation and Henrik's response helped us to find the proper invalidation mechanism. Cheers, Chris > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Thursday, October 02, 2008 1:01 PM > To: Christian Tzolov > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Can we use "no-cache" or "max-age=0" to refresh > the cached objects > > Christian Tzolov wrote: > > 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 :). > > Sorry for that. I'm sure current squid follow the RFC. Just not that I > understand the RFC well, and have not yet put in the research to be > authoritative on the answer. > > FWIW, if Mark or Henrik speak up they know a LOT more about these issues > than I do. > > > > > 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)? > > If it *receives* newer data yes. > > The catch is bug #7, if squid receives newer headers, but not actually a > newer object. > > Some squid releases are subject to bug #7 on all traffic which gets > swapped to disk cache. All current releases are subject to it under > certain conditions. > The best release which escapes most of the bug is currently 2.7.stable4. > Though one side case with IMS requests was just fixed and solved this > week. > > > 2. Squid does not change/optimize its behavior under high load in way > > that could affect assumption (1)? > > No Squid always uses the same optimal or sub-optimal behavior. The only > things which cause a change are re-configuration. Or a network failure > causing a change in data source. > > > 3. If (1) holds is this a (HTTP) standard behavior or Squid > > implementation? > > HTTP standard. Squid follows the RFC as closely as we can make it. > Currently it follows the HTTP/1.0 standard closely, with as much as we > can improved towards HTTP/1.1 behavior, which is backwards-compatible. > > Amos > > > > > 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. > > > -- > Please use Squid 2.7.STABLE4 or 3.0.STABLE9 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.
