I've got a bit of a situation going on with our caching solution and would love some input.

We use a solution of HAProxy -> Varnish -> Apache. HAProxy terminates SSL and sends that to Varnish which then requests from Apache if needed.

We are using Drupal 7, Purge, and Cache Expiration. We have Cache Expiration set to use external expiration and include the baseurls. Our sites have "Minimum cache lifetime" set to "none" and "Expiration of cached pages" set to "6h".

The Varnish cache always has the correct versions of the cached pages and those get expired correctly.

If an anonymous user visits a page, say node/123, and then logs in and subsequently navigates back to the same page the browser still serves the browser cached version of the page. This is the expected behavior from Drupal as I would expect the page to stay cached for an anonymous user.

Our content editors are required to reload the page (F5) and think there is an "error" because they need to perform this in order to see the expected, authenticated, version of their page.

How do other administrators who allow editing on production instances tackle the issue?

I toyed around with the idea of shortening the cache lifetime that comes out of Varnish, but that feels like a band-aid (30s cache vs. 6h). I also toyed with the idea of removing the cache headers coming out of Varnish, but allowing Varnish to hold the cache for its lifetime.

I'd like to be able to cache responses to keep the load off of our server if at all possible.

Thanks in advance!

2 Answers 2


See the answer to this question: https://drupal.stackexchange.com/a/117984/3279

Example usage for the D6 varnish module can seen here: https://www.drupal.org/node/738420

So, you could do a hook_form_alter in a custom php module for D7 that adds an additional submit handler to your nodes that basically calls the D7 equivalent code to clear the varnish caches for the 1 node path path/aliases in question.

  • The issue is not that Varnish is not being expired. The issue is that the browser clients are holding on to a cached version and not checking the server for updated content. Sep 19, 2017 at 12:45

I ended up solving this by making sure that our proxy sent out the following header for cacheable pages.

Cache-Control: public, max-age=0

The behavior I was experiencing was due to page_cache_maximum_age being set, and in reality I didn't want that being sent to clients, only my caching server.

sub vcl_backend_response() { if (not static content && !beresp.uncacheable) { unset beresp.http.Cache-Control; set beresp.http.Cache-Control = "public, max-age=0"; } }

  • 1
    This seems like a good way to do it. Have varnish cache it and tell the browser to not cache so editors can check ASAP without their browser cache getting in the way. webpagetest.org with First View and Repeat View selected is a good way to test the browser cache.
    – mikeytown2
    Sep 22, 2017 at 1:37
  • 1
    It turns out that we also had $conf['omit_vary_cookie'] = TRUE; in our settings.php which was causing this issue to begin with. Feb 5, 2020 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.