Problem/Motivation
Drupal introduced a simple built-in reverse proxy for anonymous users many years ago. It called this "Internal Page Cache", or "Page Cache" module for short. To communicate what it's done for a given response, it uses the X-Drupal-Cache response header.
For Drupal 8,
#2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!) →
added a more advanced variant: one that is aware of variants for users with different roles, but is also smart enough to exclude per-user or per-session parts of the page (and let those be rendered later). We called this the "Dynamic Page Cache" module. To follow the pre-existing module's lead, it went with X-Drupal-Dynamic-Cache.
Those are the two built-in reverse proxies. They already can make a big difference in performance and scalability. But if you add an external reverse proxy such as Varnish or even a geographically distributed one (a CDN), it becomes even more interesting.
It also becomes more difficult to understand what the chain of reverse proxies (HTTP caches) is that affected the response. Especially if a stale response was served by one of them, and the next one in the chain then also caches it for a period of time, this can become tricky to debug.
Wouldn't it be great if there were a standardized way to communicate this?
Proposed resolution
That's what https://httpwg.org/http-extensions/draft-ietf-httpbis-cache-header.html proposes 🥳
It's currently a draft spec that's being proposed as a future standard. That means that now is the time to attempt to implement this and provide feedback. It proposes a Cache response header to which HTTP caches can append additional information, hence allowing the end user to analyze and the developer to debug potential caching problems (or of course just verify that it's all working as intended).
It defines precise semantics for possible "cache actions". We've been using HIT and MISS for X-Drupal-Cache. We've been using HIT, MISS and UNCACHEABLE for X-Drupal-Dynamic-Cache.
In
📌
Improve X-Drupal-Cache and X-Drupal-Dynamic-Cache headers, even for responses that are not cacheable
Needs work
, we've already been working the usefulness of those two Drupal response headers, to provide more specific information why a particular response was not cached. This is of course related to that.
Remaining tasks
TBD
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
TBD