Problem/Motivation
Follow-up from #2257709: Remove the interdependence between the internal page cache and management of the Cache-Control header for external caches.
Currently the UNIX timestamp is used for the ETag
header when serving pages cacheable by proxies and/or the browser. This does not strictly conform to the specification (RFC 2616, Section 13.3) because the ETag
is expected to be a strong validator. The UNIX timestamp does not qualify as a strong validator. In order to comply with the RFC, it is either necessary to explicitly mark the ETag
as a being weak or alternatively compute a hash of the content and use that.
Upon cache-revalidation the method used check whether a 304 Not modified can be issued also does not really conform to the spec according to @Wim Leers (#2257709-5: Remove the interdependence between the internal page cache and management of the Cache-Control header for external caches):
It is not required for both
If-Modified-Since
andIf-None-Match
to be specified to trigger a 304 response. If both anETag
and aLast-Modified
response header are specified, then UAs SHOULD use both for HTTP revalidation, but it's not a requirement.
In fact the Symfony Response
object already supports cache-revalidation out of the box via the isNotModified() method. However, using this method unmodified would effectively revert #327269: drupal_page_cache_header() should compare timestamp. This needs further investigation (sifting through the Symfony issue tracker, testing with browsers / proxies).