Resolving contradictory Cache-Control headers

Question

I am maintaining a Restify server using a static content plugin. The plugin imposes a Cache-Control header despite anything that happened beforehand. max-age is always included, and defaults to 3600.

Cache-Control: public, max-age=3600

I need to have a large max-age for everything except index.html.

server.pre((req, res, next) => {
    const path = url.parse(req.url);
    if (path.pathname === '/' && req.accepts('text/html')) {
        req.url = '/public/index.html';

        // Encourage the client to always download index.html.
        res.header('Expires', '0');
        res.header('Cache-Control',
            'no-store, no-cache, must-revalidate, max-age=0');
    }

    next();
});

The problem is that the static server's forced addition of Cache-Control causes the server to send contradictory max-age values.

Cache-Control:no-store, no-cache, must-revalidate, max-age=0
Cache-Control:public, max-age=315360000

I tried something to stop this that did not work, but is this even an issue? I don't know if browsers will resolve the contradiction by downloading index.html fresh (which is what I want)

score 0 · Answer 1 · edited May 23 '17 at 12:02

Quote Michael Krebs:

I believe max-age=0 simply tells caches (and user agents) the response is stale from the get-go and so they SHOULD revalidate the response (eg. with the If-Not-Modified header) before using a cached copy, whereas, no-cache tells them they MUST revalidate before using a cached copy. From 14.9.1 What is Cacheable [...]

This quote is somewhat out of context for brevity, but the language of the spec makes max-age a "weaker" directive than no-cache, must-revalidate, etc. The actual behavior is still an implementation detail in browsers, but if max-age occurs near directives that strongly tell the browser to re-validate or not cache, it should be reasonable to expect that the browser will comply (Corroborating answer).

Resolving contradictory Cache-Control headers

1 Answers1