Hi There,
This may be a biblical / philosophical question but when teaching people
Varnish ive been struggling to justify leveraging the builtin.vcl - Mainly
vcl_recv in builtin.vcl
Since Varnish 1.0 the builtin (or default) vcl_recv has had this statement:
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
My issue with this is the req.http.Cookie check, In any modern website
cookies are always present.
This means that out of the box Varnish doesnt cache any content, which may
be an ok safe starting point but without the cookie check the default
implementation of most webservers/applications would cache static content
and not cache on dynamic content (HTML) - via cache-control / set-cookie
response headers etc - A good outcome.
Aside from the above poor caching start point (which could be ok from a low
risk kickoff perspective), biggest issue with the cookie check is that it
forces the user into a cookie management strategy.
The most common scenario we hit is that users try to "do the right thing"
and remove individual cookies so that they can fall through to underlying
vcl_recv cookie check.
The ends in disaster when marketing departments, other parts of the IT
departments or anyone involved in the website such as SEO agencies; add an
additional cookie to the site. A classic example of this is someone adding
javascript via Google Tag Manager which then sets a cookie.
The outcome of the above scenario is that suddenly the cache stops doing
anything because there is a new cookie that is not "managed" and hence all
requests, both static and dynamic "pass" via the underlying builtin.vcl
logic.
Do you still recommend configurations fall through to the underlying
vcl_recv logic?
Options i can think of:
1) Build lots of cookie whitelist/blacklist functionality above builtin.vcl
so the underlying logic doesnt break things
2) Remove cookies entirely for some request types (such as static objects)
so the underlying logic always works for some content types - My experience
is that this generates issues on some customers sites as they have static
handlers that are looking for a cookie in the origin and then do
redirects/change response content if no cookies are present.
3) Explicitly handle all scenarios and return(pass) or return(hash) to
avoid vcl_recv in builtin.vcl (and lift up the good bits of vcl_recv into
the main config)
Interested in your views, As i work on internet facing websites - I would
have thought this was the most common scenario but maybe there are more
users doing other things with Varnish or i'm missing something simple in
terms of handling cookies?
Matt
This may be a biblical / philosophical question but when teaching people
Varnish ive been struggling to justify leveraging the builtin.vcl - Mainly
vcl_recv in builtin.vcl
Since Varnish 1.0 the builtin (or default) vcl_recv has had this statement:
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
My issue with this is the req.http.Cookie check, In any modern website
cookies are always present.
This means that out of the box Varnish doesnt cache any content, which may
be an ok safe starting point but without the cookie check the default
implementation of most webservers/applications would cache static content
and not cache on dynamic content (HTML) - via cache-control / set-cookie
response headers etc - A good outcome.
Aside from the above poor caching start point (which could be ok from a low
risk kickoff perspective), biggest issue with the cookie check is that it
forces the user into a cookie management strategy.
The most common scenario we hit is that users try to "do the right thing"
and remove individual cookies so that they can fall through to underlying
vcl_recv cookie check.
The ends in disaster when marketing departments, other parts of the IT
departments or anyone involved in the website such as SEO agencies; add an
additional cookie to the site. A classic example of this is someone adding
javascript via Google Tag Manager which then sets a cookie.
The outcome of the above scenario is that suddenly the cache stops doing
anything because there is a new cookie that is not "managed" and hence all
requests, both static and dynamic "pass" via the underlying builtin.vcl
logic.
Do you still recommend configurations fall through to the underlying
vcl_recv logic?
Options i can think of:
1) Build lots of cookie whitelist/blacklist functionality above builtin.vcl
so the underlying logic doesnt break things
2) Remove cookies entirely for some request types (such as static objects)
so the underlying logic always works for some content types - My experience
is that this generates issues on some customers sites as they have static
handlers that are looking for a cookie in the origin and then do
redirects/change response content if no cookies are present.
3) Explicitly handle all scenarios and return(pass) or return(hash) to
avoid vcl_recv in builtin.vcl (and lift up the good bits of vcl_recv into
the main config)
Interested in your views, As i work on internet facing websites - I would
have thought this was the most common scenario but maybe there are more
users doing other things with Varnish or i'm missing something simple in
terms of handling cookies?
Matt