Cache Contexts do bubble now, but there is no easy way to see what cache contexts are present on a page.
Similar to the X-Drupal-Cache-Tags add a X-Drupal-Cache-Contexts header to aid in debugging.
- Write patch
- None
- Output of a new header that will be very useful for debugging.
| Issue category | Task, because its a simple task. |
|---|---|
| Issue priority | Normal, because while important for debugging, it does not break anything to not have it. |
| Prioritized changes | The main goal of this issue is to help with debugging our new cache context system. |
| Disruption | Not disruptive due to nothing changing, just an addition of a HTTP header. |
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | x_drupal_cache_contexts_header-2445761-5.patch | 5.57 KB | wim leers |
Comments
Comment #1
fabianx commentedComment #2
wim leersInitial patch. Testless.
Comment #3
wim leersAnd cleaner/simpler version.
Comment #4
fabianx commentedReally nice, just needs some tests.
Comment #5
wim leersDone.
Comment #6
fabianx commentedWhat should I say:
- Code is simpler
- Tests are better
- Debugging is nicer
I guess I say: RTBC! :)
Comment #7
nielsvm commentedOne of the awesome ideas this allows (indeed) is to let Varnish do this:
hash_data(req,url, req.X-Drupal-Cache-Contexts);https://www.varnish-software.com/static/book/VCL_functions.html#vcl-vcl-...
+1;
Comment #8
fabianx commented#7:
Yes, that is the plan too, but its not as simple as that, because the hash is for the original CID not the what comes in via the reply of the backend.
The trick is to have Drupal and Varnish negotiate a list of Cache Contexts that Varnish supports (e.g. by querying Drupal once and caching those not changing things per SESSION as the path /cache-contexts/user (so that it can be invalidated if something changes on that)).
Then with the restart functionality indeed this header can be used to differentiate the hash, based on the contents of the Cache Contexts. (resolved within Varnish itself).
Comment #9
wim leers#7 & #8: Yes, those are nice side-effects, but that's not the actual goal of this issue. Let's keep that discussion for another issue :)
Comment #10
berdirJust wondering, is it possible that a cache context could be exposing some kind of data that you wouldn't want to be visible?
Comment #11
wim leersAnother important use case for this: tests. Without this header, it's nigh impossible to check if a certain cache context is present on a page.
#10: I wondered the same back when I added
X-Drupal-Cache-Tags, which has far more sensitive data (the *exact* things on the page) and it was deemed not problematic. Since this doesn't list the *exact* values for the cache contexts, but just the various cache contexts in play on a particular page (which anybody can find by grepping Drupal core/contrib), I don't see how this could ever amount to information disclosure.Comment #12
alexpottCommitted 7eaa1b7 and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.