cache empties itself?

[Ricardo Newbery]

On Apr 3, 2008, at 12:45 PM, Michael S. Fischer wrote:

> On Thu, Apr 3, 2008 at 11:53 AM, Ricardo Newbery <ric at digitalmarbles.com 
> > wrote:
>> On Apr 3, 2008, at 11:04 AM, Michael S. Fischer wrote:
>>> On Thu, Apr 3, 2008 at 10:58 AM, Sascha Ottolski <ottolski at web.de>  
>>> wrote:
>>>
>>>> and I don't wan't upstream caches or browsers to cache that long,  
>>>> only
>>>> varnish, so setting headers doesn't seem to fit.
>>>>
>>>
>>> Why not?  Just curious.   If it's truly cachable content, it seems  
>>> as
>>> though it would make sense (both for your performance and your
>>> bandwidth outlays) to let browsers cache.
>>
>> Can't speak for the OP but a common use case is where you want an
>> aggressive cache but still need to retain the ability to purge the  
>> cache
>> when content changes.  As far as I know, there are only two ways to  
>> do this
>> without contaminating downstream caches with potentially stale  
>> content...
>> via special treatment in the varnish config (which is what the OP  
>> is trying
>> to do) or using a special header that only your varnish instance will
>> recognize (like Surrogate-Control, which as far as I know Varnish  
>> does not
>> support out-of-the-box but Squid3 does).
>
> Seems to me that this is rather brittle and error-prone.
>
> - If a particular resource is truly dynamic, then it should not be
> cachable at all.
> - If a particular resource can be considered static (i.e. cachable),
> yet updateable, then it is *far* safer to version your URLs, as you
> have zero control over intermediate proxies.
>
> --Michael



If done correctly, this is neither brittle nor error-prone.  This is  
the point after all of the Surrogate-Control header -- A way for your  
backend to instruct your proxy (or "surrogate" if you insist) how to  
handle your content in a way that is invisible to intermediate proxies  
not under your control.

While not as flexible as the Surrogate-Control header, you can do the  
same just with special stanzas in your varnish.vcl.  In fact, the vcl  
man page contains one example of how to do this for all objects to  
enforce a minimum ttl:

          sub vcl_fetch {
              if (obj.ttl < 120s) {
                  set obj.ttl = 120s;
              }
          }

Or you can invent your own header... let's call it  X-Varnish-1day

          sub vcl_fetch {
              if (obj.http.X-Varnish-1day) {
                  set obj.ttl = 86400s;
              }
          }

Neither of these two examples are "unsafe" and both are invisible to  
intermediate proxies.

With regards to URL versioning, this is indeed a powerful strategy --  
assuming your backend is capable of doing this.  But it's a strategy  
generally only appropriate for supporting resources like inline  
graphics, css, and javascript.  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.

Ric