When should same policies be added under both vcl_recv and vcl_fetch?

Question

Let me explain with an example:

File: /etc/varnish/default.vcl

# [...]

sub vcl_recv {

    # [...]

    if (req.request != "GET" && req.request != "HEAD") {
        return (pass);
    }

    if (req.http.Authorization || req.http.Authenticate) {
        return (pass);
    }

    if (req.url ~ "wp-(login|admin|comments-post.php|cron.php)") {
        return (pass);
    }

    # [...]

    return (lookup);
}

sub vcl_fetch {

    # [...]

    if (req.request != "GET" && req.request != "HEAD") {
        return (hit_for_pass);
    }

    if (req.http.Authorization || req.http.Authenticate) {
        return (hit_for_pass);
    }

    if (req.url ~ "wp-(login|admin|comments-post.php|cron.php)") {
        return (hit_for_pass);
    }

    # [...]

    return (deliver);
}

As you can see, for content that shouldn't be cached, I have same policies under vcl_recv and vcl_fetch but with return (pass); and return (hit_for_pass); respectively.

There are some cases when this should be done (when it is useful), and others where this is absolutely unnecessary. What are they? (e.g. Cookies? If so, how?)

score 1 · Accepted Answer · answered Jun 19 '14 at 18:12

I really cannot see why there should be any case where this is useful. You create hit-for-pass objects when the VCL has no idea that the resulting response cannot be caches. If the VCL can figure our that the response should not be cached you should just "pass" and be done with it, avoiding the whole hit-for-pass creation.

So, the advice is pretty simple. You use pass in recv when you can, but if you don't know about the cacheabilty of the object you should fall back to having Varnish create hit-for-pass objects and thereby avoiding serialising transactions.

When should same policies be added under both vcl_recv and vcl_fetch?

1 Answers1