[varnish] Re: Handling of cache-control

[Ricardo Newbery]

On Jan 18, 2010, at 4:37 PM, Poul-Henning Kamp wrote:

> In message <DE028C9E-4618-4EBC-8477-6E308753CBCE at dynamine.net>,  
> "Michael S. Fis
> cher" writes:
>> On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote:
>
>>> My suggestion is to also look at Cache-control: no-cache, possibly  
>>> also
>>> private and no-store and obey those.
>>
>> Why wasn't it doing it all along?
>
> Because we wanted to give the backend a chance to tell Varnish one
> thing with respect to caching, and the client another.
>
> I'm not saying we hit the right decision, and welcome any consistent,
> easily explainable policy you guys can agree on.



IMHO, the private token should be added to the list that Varnish  
supports out-of-the-box as there is probably a very good reason why  
the backend wants to keep private responses out of any shared caches.   
I'm ambivalent about the others.  The no-store and no-cache tokens can  
be a problem for IE in certain usecases so I try to discourage their  
use.  Instead I just set maxage=0 with no etag/lastmodified which for  
most practical cases is pretty much equivalent.  In practice, I  
usually add all three tokens (private, no-store, no-cache) to vcl  
anyway just to cover my bases.

Other than the private token, the other thing I used to do to tell  
Varnish and clients to cache differently is to attach a special header  
like X-CacheInVarnishOnly or some such (support in Varnish for  
Surrogate-Control would be a better solution).  But recently, I came  
across another strategy.  As far as I can tell, there is no good  
usecase for a non-zero s-maxage token outside your reverse-proxy.  So  
now I just use the s-maxage token to tell Varnish how to cache and  
then strip it from the response headers (or reset to s-maxage=0) to  
avoid contaminating any forward proxies downstream.

Cheers,
Ricardo Newbery
http://digitalmarbles.com