[varnish] Re: Handling of cache-control

[Ricardo Newbery]

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