Cfrgtkky

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!

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.

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

}