Varnish + Wordpress + Nginx - Prevent no-store no-cache must-revalidate headers

0
votes

We launched a web app about a week ago, experienced a heavy load spike and were down for almost 2 hours. I won't mention the company by name, but we were leaning on them for recommendations to prevent this exact thing.

They said that since we were using Varnish, we could handle the traffic influx quite easily. However, we didn't verify caching was working as intended. It was not.

TLDR: Our web app is sending Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 headers with requests and there's no indication of why that is.

Where can I look to prevent these headers from being sent?

PHP: 5.6 Nginx: 1.4.6 Varnish: 1.1 Wordpress: 4.6.12 Timber: 1.2.4

The linux admins we're working with have said they scoured the configs and haven't found anything specifying those headers except for AJAX requests.

#dont cache ajax requests

if(req.http.X-Requested-With == "XMLHttpRequest" || req.url ~ "nocache" || req.url ~ "(control.php|wp-comments-post.php|wp-login.php|bb-login.php|bb-reset-password.php|register.php)")

Here's a curl from Pre-launch when we correctly configured Varnish to cache after forcing HTTPS(force-https plugin) on the site:

$ curl -Ik -H'X-Forwarded-Proto: *************
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Server: *****
Date: Sat, 03 Nov 2018 22:36:43 GMT
X-Varnish: 53061104
Age: 0
Via: 1.1 varnish
Connection: keep-alive

And from post launch:

curl -ILk ***********
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
X-Varnish: 691817320
Vary: Accept-Encoding
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=UTF-8
X-Server: ****
Date: Mon, 19 Nov 2018 19:17:02 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Accept-Ranges: bytes
Via: 1.1 varnish
Connection: Keep-Alive
Set-Cookie: X-Mapping-fjhppofk=33C486CB71216B67C5C5AB8F5E63769E; path=/
Age: 0

Force-https plugin: We activated this, updated the Varnish config to avoid a redirect loop and confirmed it was working a week prior to launch.

Plugins: These did not change, except for force-https.

Web App: It's an updated version of the previous app, complete redesign but nothing in the app from what I can tell is specifying no-store no-cache headers to be sent.

Where should I start? Thanks!

2
wordpressnginxvarnishvarnish-vcltimber

2 Answers

3
votes

What is sending these headers is PHP engine.

It does so whenever you initiate a session, which clearly happens based on Set-Cookie presence.

Make sure that PHP sessions are initiated only when absolutely needed. By default, Varnish will not cache when response includes either Set-Cookie or "negative" Cache-Control, you have both.

So getting rid of extraneous session_start() and/or setcookie() calls is the key here.

You can find more info on when you can expect anti-caching headers sent here.

1
votes

You need to fix the backend, but at the very least, you can strip the annoying header, and/or bypass it in varnish with this vcl snippet;

sub vcl_backend_response {
    # kill the CC header so that application downstream don't see it
    unset req.http.Cache-Control;

    # alternatively, you can also override that header with
    # set req.http.Cache-Control = "whatever string you desire";

    # you can also force the TTL
    beresp.ttl;

    # also, if you return now, the builtin.vcl (https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishd/builtin.vcl)
    # doesn't get executed; this is generally the one deciding content is uncacheable
    return (deliver);
}