Active
Project:
Drupal core
Version:
main
Component:
cache system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
25 Mar 2014 at 17:52 UTC
Updated:
8 Jun 2019 at 15:14 UTC
Jump to comment: Most recent
Comments
Comment #1
drifter commentedSounds good, but couldn't the cache tag header potentially grow very large? Maybe we should use a hash of the tags?
Comment #2
znerol commentedIn the other discussion it has been pointed out already that cache-tags alone are not enough to generate an
ETag. I.e. when content is updated, it is perfectly possible that the list of tags remain the same. In order to generate anETag, the invalidation counts (or checksum) needs to be included also #2217371-9: Expose cache tags to reverse proxies: X-Drupal-Cache-Tags header (by just slightly changing an existing header).However, the invalidation count / checksum is an implementation detail. For example there is a PoC of the Redis cache backend (#2233413: Port Redis to Drupal 8), which is solely based on server-side set-operations for invalidation.
I feel that making the checksum mandatory for cache backend implementations in order to unify
ETagandX-Drupal-Cache-Tagswould make things more complex.Let's follow common practice and use a hash for the
ETagand continue with #2259489: Leverage symfony for HTTP revalidation.Comment #3
catchNot sure it has to be mandatory, we could add an additional interface for the checksum and decide on the Etag strategy based on that.
Posted in the other issue why I think using a content hash is going to be overly precise.
Comment #4
wim leersFor this, see #2259489-5: Leverage symfony for HTTP revalidation.
Comment #5
fabianx commentedWe do have a checksum interface now, which we could use for this.
Comment #9
wim leersComment #13
avpaderno