Stale content is served from the browser cache (Safari and/or Varnish)

Missing Vary: Cookie or buggy Browser

A web application may instruct a browser to store a page in its cache for N seconds by adding a Cache-Control: max-age=N header. As a result the browser will retrieve a page from the cache on subsequent requests. This may lead to problems upon user login/logout. The following failure mode is typical for this problem: A user visits the front page of a site (unauthenticated), then navigates to the user-login page, logs into the system, comes back to the front page and appears to be logged out again.

In order to mitigate this problem, Drupal adds the Vary: Cookie header to each cacheable response. This will instruct a browsers to only fetch a page from its cache when the value of the Cookie on the new request header is equal to the one on the original request. Because Drupal regenerates the session cookie upon login, this request header is never the same before and after login and therefore a browser never should present a page cached before login to an authenticated user.

However at least Safari 5 (iPad 1, last Windows version, some older iPhones) has a bug triggering the failure mode even when Vary: Cookie is set correctly by the web application. Therefore when serving to Safari it is necessary to avoid that a page gets cached by the browser by forcing the Cache-Control header to no-cache.

The VCL shipping with Authcache Varnish Cache Backend contains a snipped capable of disabling browser caching for Safari (see commit href="http://drupalcode.org/project/authcache.git/commit/d2af02a">d2af02a). However I feel that we also should implement something for the Authcache Bultin Cache Backend.

Steps to reproduce

In order to detect this failure mode, execute the following steps:

1. Clear the browser cache and cookies
2. Navigate to a node (e.g. node/1)
3. Navigate to user/login and authenticate
4. Navigate back to the node

Execute those steps once with the browser cache enabled and once with the browser cache disabled (e.g. by deactivating it using the developer tools of your browser).

Deficient cache revalidation because of bogus Etag

In order to save bandwidth, a browser may choose to just "ask" a web application whether it can reuse a cached copy of a resource. The mechanism relies on the following HTTP headers:

Set by the web application on the initial response:

• Cache-Control: max-age=N
• Date: <current-date>, e.g. Sat, 30 Nov 2013 14:02:40 GMT
• Etag: "12345-1"
• Last-Modified: <cache-save-date>, e.g. Sat, 30 Nov 2013 13:11:48 GMT

Set by the browser on a subsequent request:

• If-Modified-Since: Sat, 30 Nov 2013 13:11:48 GMT
• If-None-Match: "12345-1"

The web application rebuilds the page (or retrieves it from the internal cache) and determines the appropriate response using the following rules:

if request.If-None-Match == response.Etag AND request.If-Modified-Since == response.Last-Modified:
    response.status = "304 Not Modified"
    unset(response.body)
else:
    response.status = "200 OK"

return(response)

The important point here is that the Etag value must be unique for each variant of a resource. By default Drupal constructs the Etag from the unix timestamp when a cached entry was created and appends "-1" when delivering gzipped content and "-0" when sending out uncompressed content.

Authcache therefore should make sure that the Etag header added to a response always includes the authcache key, such that when browsers request a revalidation, the cache backend or the reverse proxy has a chance to validate against the correct variant.