Re: [varnish] Re: [varnish] Re: Handling of cache-control

[Bedis 9]

hey,

That way, any shared proxy cache on the path between our caches and
the client would cache the object.
Our customer didn't want this. The purpose was to have the freshest
information as close as the origin as possible.

cheers


On Thu, Jan 28, 2010 at 12:00 AM, pablort  wrote:
> Isn't this the equivalent of and max-age=5 and s-maxage=0 ?
>
> On Wed, Jan 20, 2010 at 7:19 AM, Bedis 9  wrote:
>>
>> Hi,
>>
>> Netcache devices had the X-Accel-Cache-Control headers in order to
>> allow an origin server to setup different Cache-Control parameters for
>> the cache and the end-user.
>> The netcache will follow the X-Accel-Cache-Control while the end user
>> will follow the Cache-Control.
>>
>> I've a few customer using this, mainly for sports events where "live"
>> is the key.
>> They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is
>> set to no-cache.
>> That way, all the load generated by thousends of request per second
>> for "live" stuff is offloaded to the cache layer.
>> Only a few request goes back to the origin.
>>
>>
>> I was able to reproduce such behavior with the following inline C:
>> sub vcl_fetch {
>> [...]
>> # Check if X-Accel-Cache-Control exists and follow it
>>        if (obj.http.X-Accel-Cache-Control) {
>> C{
>>        char *cache;
>>        int max_age = 0;
>>        cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:");
>>        if(cache) {
>>                char *s = NULL;
>>                /* Looking for max-age */
>>                if (s = strstr(cache, "max-age=")) {
>>                        s+=8;
>>                        max_age = strtoul(s, 0, 0);
>>                        if (max_age) {
>>                                VRT_l_obj_ttl(sp, max_age);
>>                        }
>>                }
>>        }
>> }C
>>       unset obj.http.X-Accel-Cache-Control;
>>        }
>>
>> # Cache-Control and Pragma headers preventing caching
>>        if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~
>> "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)"))
>> {
>>                pass;
>>        }
>>
>> }
>>
>> [...]
>>
>> }
>>
>>
>> Maybe it can be useful to somebody else :)
>>
>> cheers
>> ___
>> varnish-misc mailing list
>> varnish-misc@projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [varnish] Re: [varnish] Re: Handling of cache-control

[pablort]

Isn't this the equivalent of and max-age=5 and s-maxage=0 ?

On Wed, Jan 20, 2010 at 7:19 AM, Bedis 9  wrote:

> Hi,
>
> Netcache devices had the X-Accel-Cache-Control headers in order to
> allow an origin server to setup different Cache-Control parameters for
> the cache and the end-user.
> The netcache will follow the X-Accel-Cache-Control while the end user
> will follow the Cache-Control.
>
> I've a few customer using this, mainly for sports events where "live"
> is the key.
> They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is
> set to no-cache.
> That way, all the load generated by thousends of request per second
> for "live" stuff is offloaded to the cache layer.
> Only a few request goes back to the origin.
>
>
> I was able to reproduce such behavior with the following inline C:
> sub vcl_fetch {
> [...]
> # Check if X-Accel-Cache-Control exists and follow it
>if (obj.http.X-Accel-Cache-Control) {
> C{
>char *cache;
>int max_age = 0;
>cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:");
>if(cache) {
>char *s = NULL;
>/* Looking for max-age */
>if (s = strstr(cache, "max-age=")) {
>s+=8;
>max_age = strtoul(s, 0, 0);
>if (max_age) {
>VRT_l_obj_ttl(sp, max_age);
>}
>}
>}
> }C
>   unset obj.http.X-Accel-Cache-Control;
>}
>
> # Cache-Control and Pragma headers preventing caching
>if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~
> "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)"))
> {
>pass;
>}
>
> }
>
> [...]
>
> }
>
>
> Maybe it can be useful to somebody else :)
>
> cheers
> ___
> varnish-misc mailing list
> varnish-misc@projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [varnish] Re: [varnish] Re: Handling of cache-control

[Bedis 9]

Hi,

Netcache devices had the X-Accel-Cache-Control headers in order to
allow an origin server to setup different Cache-Control parameters for
the cache and the end-user.
The netcache will follow the X-Accel-Cache-Control while the end user
will follow the Cache-Control.

I've a few customer using this, mainly for sports events where "live"
is the key.
They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is
set to no-cache.
That way, all the load generated by thousends of request per second
for "live" stuff is offloaded to the cache layer.
Only a few request goes back to the origin.


I was able to reproduce such behavior with the following inline C:
sub vcl_fetch {
[...]
# Check if X-Accel-Cache-Control exists and follow it
if (obj.http.X-Accel-Cache-Control) {
C{
char *cache;
int max_age = 0;
cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:");
if(cache) {
char *s = NULL;
/* Looking for max-age */
if (s = strstr(cache, "max-age=")) {
s+=8;
max_age = strtoul(s, 0, 0);
if (max_age) {
VRT_l_obj_ttl(sp, max_age);
}
}
}
}C
   unset obj.http.X-Accel-Cache-Control;
}

# Cache-Control and Pragma headers preventing caching
if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~
"no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)"))
{
pass;
}

}

[...]

}


Maybe it can be useful to somebody else :)

cheers
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [varnish] Re: [varnish] Re: Handling of cache-control

[Ricardo Newbery]

On Jan 19, 2010, at 2:03 PM, Michael Fischer wrote:

> On Tue, Jan 19, 2010 at 1:48 PM, Ricardo Newbery  > wrote:
>
> 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.
>
> This seems logical to me.  Are there any drawbacks to using  
> Surrogate-Control?
>
> --Michael


Not that I'm aware of.  Except that only Squid 3.x supports it right  
now  ;-)

Cheers,
Ricardo Newbery
http://digitalmarbles.com

___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [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


___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [varnish] Re: Handling of cache-control

[Michael Fischer]

On Tue, Jan 19, 2010 at 1:48 PM, Ricardo Newbery wrote:

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.


This seems logical to me.  Are there any drawbacks to using
Surrogate-Control?

--Michael
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: [varnish] Re: Handling of cache-control

[Ricardo Newbery]

On Jan 18, 2010, at 4:37 PM, Poul-Henning Kamp wrote:

> In message ,  
> "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

Re: Handling of cache-control

[Rob S]

Michael Fischer wrote:
> On Mon, Jan 18, 2010 at 4:37 PM, Poul-Henning Kamp  > wrote:
>
> In message  >,
> "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.
>
>
> Well, the problem is that application engineers who understand what 
> that header does have a reasonable expectation that the caches will 
> obey them, and so I think Vanish should honor them as Squid does. 
>  Otherwise surprising results will occur when the caching platform is 
> changed.
>
> 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 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.
>
> --Michael

Michael,

You've obviously got some strong views about varnish, as we've all seen 
from the mailing list over the past few days!

When we deployed varnish, we did so in front of applications that 
weren't prepared to have a cache in front of them.  Accordingly, we 
disabled all caching on HTML and RSS type content in Varnish, and 
instead just cached CSS / JS / images.  This was a good outcome because 
we could stop using round robin DNS (which is a bit questionable, imho, 
if it includes more than two or three hosts) to the web servers, and 
instead just point 2 A records at Varnish.  We elected to use 
X-External-Cache-Control AND X-Internal-TTL as a headers that we'd set 
in Varnish-aware applications.  So, old apps that emit cache-control 
headers are completely uncached by Varnish), and new-apps can benefit to 
a certain degree of caching by Varnish.

PHK's plans for 2010 will enable us to fully exploit our X-Internal-TTL 
headers because it'll be able to parse TTL values out of headers.  In 
the meantime, these are hard-set in Varnish to a value that's 
appropriate for our apps.

The X-External-Cache-Control is then presented as Cache-Control to 
public HTTP requests.

This describes how we've chosen to deploy varnish, without causing our 
application developers huge headaches.  In parallel, we've changed many 
of our sites to use local cookies+javascript to add personalisation to 
the most popular pages.  Overall, deploying Varnish has seen a big 
reduction in back end requests, PLUS the ability to load balance over a 
large pool whilst still implementing sticky-sessions where our apps 
still need them.  Varnish is, as the name suggests, a lovely layer in 
front of our platform which makes it perform better.

Now, to answer your points: 

1) Application developers to be aware of caching headers:  I'd disagree 
here.  Our approach is to use code libraries to deliver functionality to 
the developers which the sysadmins can maintain.  There's always some 
overlap here, but we're comfortable with our position.  We're a PHP 
company, and so we've a class that's used statically, with methods such 
as Cacheability::noCache(), Cacheability::setExternalExpiryTime($secs), 
and Cacheability::setInternalExpiryTime($secs), as well as 
Cacheability::purgeCache($path).  Just as, I'm sure, your developers are 
using abstraction layers for database access, then they could use a 
simila

Re: Handling of cache-control

[Michael Fischer]

On Mon, Jan 18, 2010 at 4:37 PM, Poul-Henning Kamp wrote:

> In message , "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.


Well, the problem is that application engineers who understand what that
header does have a reasonable expectation that the caches will obey them,
and so I think Vanish should honor them as Squid does.  Otherwise surprising
results will occur when the caching platform is changed.

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 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.

--Michael
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: Handling of cache-control

[Poul-Henning Kamp]

In message , "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.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: Handling of cache-control

[Michael S. Fischer]

On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote:
> we are considering changing the defaults on how the cache-control header
> is handled in Varnish.  Currently, we only look at s-maxage and maxage
> to decide if and how long an object should be cached.  (We also look at
> expires, but that's not relevant here.)
> 
> 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?  

--Michael
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

Re: Handling of cache-control

[Laurence Rowe]

2010/1/18 Tollef Fog Heen :
>
> Hi all,
>
> we are considering changing the defaults on how the cache-control header
> is handled in Varnish.  Currently, we only look at s-maxage and maxage
> to decide if and how long an object should be cached.  (We also look at
> expires, but that's not relevant here.)
>
> My suggestion is to also look at Cache-control: no-cache, possibly also
> private and no-store and obey those.  You would still be able to
> override this in vcl by setting obj.cacheable to true and the ttl to
> some value.
>
> The reason I think we should at least consider changing this is the
> principle of least surprise: we support max-age and s-maxage, so we
> should also support the other common values of the cache-control header
> field.
>
> Feedback very welcome,

Given the proposed move away from having the default vcl, it would
seem logical to move cache-control header logic into VCL. The less
magic that happens behind the scenes, the easier it is to understand
what a particular configuration will do.

Laurence
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc