CODEWITHSUNDEEP
cachingreverse-proxyvarnishvarnish-vcl
its_me
its_me

Reputation: 11358

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

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?)

Upvotes: 2

Views: 153

Answers (1)

perbu
perbu

Reputation: 440

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.

Upvotes: 1

Related Questions