[varnish] Re: Handling of cache-control
ric at digitalmarbles.com
Tue Jan 19 22:48:23 CET 2010
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
>>> 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.
More information about the varnish-misc