cache empties itself?

[Ricardo Newbery]

On Apr 3, 2008, at 7:46 PM, Michael S. Fischer wrote:

> On Thu, Apr 3, 2008 at 7:37 PM, Ricardo Newbery <ric at digitalmarbles.com 
> > wrote:
>
>> URL versioning is usually not appropriate for html
>> pages or other primary resources that are intended to be reached  
>> directly by
>> the end user and whose URLs must not change.
>
> Back to square one.  Are these latter resources dynamic, or are they  
> static?
>
> - If they are dynamic, neither your own proxies nor upstream proxies
> should be caching the content.
> - If they are static, then they should be cacheable for the same
> amount of time all the way upstream (modulo protected URLs).
>
> I've haven't yet seen a defensible need for varying cache lifetimes,
> depending on the proximity of the proxy to the origin server, as this
> request seems to be.  Of course, I'm open to being convinced otherwise
> :-)


Well, first of all you're setting up a false dichotomy.  Not  
everything fits neatly into your apparent definitions of dynamic  
versus static.  Your definitions appear to exclude the use case where  
you have cacheable content that is subject to change at unpredictable  
intervals but which is otherwise fairly "static" for some length of  
time.

Sometimes, in such a case, serving stale content for some time after  
an edit is an acceptable compromise between performance and freshness  
but often it is not.   And sometimes, impacting overall performance by  
hitting the backend for every such request is also undesirable.

Thankfully, those are not the only choices.  With a combination of  
PURGE requests and something like Surrogate-Control (or hardcoded  
behavior in your reverse-proxy config), you can still insure immediate  
freshness (or whatever level of freshness you require) without forcing  
your backend to do all the work.

Ric