On Jan 18, 2010, at 4:37 PM, Poul-Henning Kamp wrote: > In message <de028c9e-4618-4ebc-8477-6e308753c...@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 _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
