This module suggests that the "Browser and proxy cache maximum age" be set to a larger value - even an year. This setting is the same used by the web browsers, isn't it? So if a visitor checks a page and then visits the same page after sometime during which updates might have occurred, s/he might not receive the updated version since the web browser will not even contact the caching server until the browser cache expires.

What is needed is a way to set that value to something like 15 minutes or so, but get the external caching servers linked to cache the content for months or more.

I would ideally like the modules like Advanced Page Expiration be used to control the browser cache time, but use the purge module to purge the content in the external caching servers.

Personally, I use Varnish. I wonder how to accomplish what I want.

I could not find details about how to get the envisioned setup configured. Or else, is the purge module limited to get the updated content only to the new browser clients, but not the previously accessed ones.

Or else, have I understood something incorrectly?

Kamal

Comments

kamalw created an issue. See original summary.

kamalw’s picture

kamalw commented

I fond this after writing the above: "How to cache things longer on Varnish than on the client".

I wonder if Drupal uses the s-maxage header. Symfony code does have 's-maxage' here and there. May be we need a module to set that?

kamalw’s picture

kamalw commented

Then I found HTTP Cache Control. It seems to support setting the s-maxage. It has only a beta release module for Drupal 8 as of now. I should test it anyway.

yivanov’s picture

yivanov commented

I am asking myself the same question, seeing that 1 year is the recommended cache max-age (browser cache). It is also true that in the real world the browser cache has limited space and the chance of getting the same asset in a year is near to 0.
The only explanation I could think of is that the browser indeed will send request to the server to check if the asset has changed and will get 304 Not Modified response. This is good from the perspective that the user visiting can get the new page even though it is cached already by the browser.

o'briat’s picture

o'briat
Primary language French
Location Nantes
commented

"1 year (recommended for external cache invalidation)" seems a bad recommendation if you don't know how to correct it before send it to visitors browser.
This setting tells ALL cache systems : Varnish, reverse proxies, CDN, ... including visitors browsers to cache the data for one year (cache-control: public, max-age=315360000).

This is fine for system that can be purged by this module (like Varnish), but for "out of reach" caches such as your visitors browsers, cache will never be purged!

Since "s-maxage" is not implemented and etag doesn't seems to be used in all case, you have to alter the "cache-control" header when the requests exit your network.

There is two temporary solutions :
1. Set a high cache max-age in Drupal (used by your cache servers), but rewrite it when you send it to browser (my solution,see below)
2. Set a "standard" max-age (less than 1 hour), but change you cache server ttl to a higher value

My default.vcl 

    # Enforce default max-age to 1 hour whatever is set in Drupal (/admin/config/development/performance)
    if (beresp.http.Cache-Control ~ "max-age=") {
        unset beresp.http.Cache-Control;
        unset beresp.http.expires;
        # Cache-control send to the browser.
        set beresp.http.Cache-Control = "public, max-age=3600";
    }

My suggestion is that Purge adds a specific "s-maxage" settings and provide more documentation about "max-age" and "s-maxage" tuning and side-effects.

o'briat’s picture

o'briat
Primary language French
Location Nantes
commented
Priority: Normal » Major
dieterholvoet’s picture

dieterholvoet commented
Related issues: +#3062871: Cache Max Age warning text