Problem/Motivation
- Large headers slow down communication between client and server.
With the headers attackers may be able to identify sections of a page that are not cached and may start a targeted DDoS.- Many hosting environments impose limits on the header size, and for a sufficiently complex Drupal 8 page, the number of cache tags on that page (i.e. the number of things that page depends on) can cause the cache tags header to go beyond 4 KB, causing WSODs.
- When setting up a reverse proxy in front of a site that uses cache tags for instantaneous invalidation, these headers do not help much anyway: A) you need a Drupal module to talk to the reverse proxy anyway, to inform them which cache tags are being invalidated, B) commercial services require specific names (Fastly:
Surrogate-Keys, CloudFlare:Cache-Tag) and a specific format for the value (Fastly: space-separated, like Drupal, CloudFlare: comma-separated). So, you effectively need a module anyway, so there is no point in always sending these headers: it doesn't actually simplify integrating with a reverse proxy.
Proposed resolution
Core provides the ability to send these headers for debugging purposes. WebTestBase enables them by default, so that it's easy to write cacheability tests. For debugging, one enables them by setting a container parameter (in services.yml) plus a container rebuild.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.