Problem/Motivation
We've discovered a lot of bugs lately where cacheability variations are not correctly taken into account. E.g.
📌
Cacheability information from route access checker access results are ignored by dynamic_page_cache
Needs review
.
The basic problem is that one part of request-handling code, such as access control, or part of the controller, sets a cacheability with contexts, say, [foo, bar], and a subsequent part of the handling code sets a disjoint cache context, say, ['foo, biz'].
This leads to bugs where users can see incorrect content, or be incorrectly denied access.
Steps to reproduce
Proposed resolution
Persist the cacheability object across the lifetime of the request, so that when handling code sets cache context, it can only *refine* the context that has been set so far, and cannot set a disjoint context.
We could do this by adding cacheability to the $request object, which request handling code can easily get hold of.
(It would make more sense to add it to a $response object, but we don't have a way to pass that around, and I don't see how it would work with all the code that expects to be able to create and return a specialised response class.)
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet