I am using Varnish 3.0.3 and to use it to leverage browser caching by setting a maximum age in the HTTP headers for static resources. I tried adding the following configuration to default.vcl:
sub vcl_fetch {
if (beresp.cacheable) {
/* Remove Expires from backend, it's not long enough */
unset beresp.http.expires;
/* Set the clients TTL on this object */
set beresp.http.cache-control = "max-age=900";
/* Set how long Varnish will keep it */
set beresp.ttl = 1w;
/* marker for vcl_deliver to reset Age: */
set beresp.http.magicmarker = "1";
}
}
sub vcl_deliver {
if (resp.http.magicmarker) {
/* Remove the magic marker */
unset resp.http.magicmarker;
/* By definition we have a fresh object */
set resp.http.age = "0";
}
}
This is copied from https://www.varnish-cache.org/trac/wiki/VCLExampleLongerCaching . Maybe I just made a typo. On restart of Varnish, it no longer worked.
I have two questions. Is this the correct way to do it for Varnish 3? If so, what am I doing wrong? Secondly, is there a way to test the Varnish configuration file, before a restart? Something along the ways of what Apache has with "/sbin/service httpd configtest". That catches mistakes before going live. Thank you.
Yes, in general this is the way of overriding the backend's TTL. Remove beresp.http.expires, set beresp.http.cache-control, set beresp.ttl. beresp.cacheable is a 2.[01]-ism. The same test in 3.0 is to check that beresp.ttl > 0.
A small tip is to store your magic marker on req.http instead, then you don't have to clean it up before handing the object to the client.
With regards to testing a configuration file, you can call the VCL compiler directly with "varnishd -C -f /etc/varnish/default.vcl" for example. If your VCL is faulty you get the error message, if the VCL is valid you get a few pages with generated C code.