<div dir="ltr">Hi There,<br><br>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<br><br>Since Varnish 1.0 the builtin (or default) vcl_recv has had this statement:<br>if (req.http.Authorization || req.http.Cookie) {<br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">/* Not cacheable by default */</blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">return (pass);</blockquote>}<div><br></div><div>My issue with this is the req.http.Cookie check, In any modern website cookies are always present.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Do you still recommend configurations fall through to the underlying vcl_recv logic?</div><div><br></div><div>Options i can think of:</div><div>1) Build lots of cookie whitelist/blacklist functionality above builtin.vcl so the underlying logic doesnt break things</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>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?</div><div><br></div><div>Matt</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>