On Jan 19, 2010, at 10:26 AM, Michael Fischer wrote: > Cache-Control: private certainly meets the goal you stated, at least > insofar as making Varnish behave differently than the client -- it > states that the client can cache, but Varnish (as an intermediate > cache) cannot.
I'm being pedantic but... technically I believe private is just ignored by browsers, which amounts to the same thing :-) > I assume, however, that some engineers want a way to do the opposite > - to inform Varnish that it can cache, but inform the client that it > cannot. Ordinarily I'd think this is not a very good idea, since > you almost always want to keep the cached copy as close to the user > as possible. But I guess there are some circumstances where an > engineer would want to preload a cache with prerendered data that is > expensive to generate, and, also asynchronously force updates by > flushing stale objects with a PURGE or equivalent. In that case the > cache TTL would be very high, but not necessarily meaningful. > > I'm not sure it makes sense to extend the Cache-Control: header > here, because there could be secondary intermediate caches > downstream that are not under the engineer's control; so we need a > way to inform only authorized intermediate caches that they should > cache the response with the specified TTL. > > One way I've seen to accomplish this goal is to inject a custom > header in the response, but we need to ensure it is either encrypted > (so that non-authorized caches can't see it -- but this could be > costly in terms of CPU) or removed by the last authorized > intermediate cache as the response is passed back downstream. Storing responses only in your reverse-proxy and out of the browser cache is a common usecase for a CMS. Otherwise, a content change may not propagate to your users unless you force them all to do conditional requests to your backend. A custom header works. So would the Surrogate-Control header if Varnish supported it -- this is exactly the usecase this header was intended for. But these days, I've begun using s-maxage as a surrogate for Surrogate-Control and just stripping it from the final response -- not as flexible as Surrogate-Control but it does everything I need right now. Regards, Ricardo Newbery http://digitalmarbles.com _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
