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