If you want to return different responses for the same request, depending on values of HTTP headers, resulting response cannot be cached neither in internal nor in external response-level cache.
Examples of such requests:
- Browser language negotiation (
🐛
Browser language detection is not cache aware
Needs work
) should have different results depending on visitor's language preferences, sent in "Accept-Language" header.
- Site needs to display local sales office to people depending on their originating country. Many CDN providers (Cloudflare, Akamai etc.) sent this information in HTTP header.
The only existing way to return headers-dependent response is to mark it non-cacheable (use KillSwitch policy). That happens because cacheability metadata that contains "header" context (implemented in HeadersCacheContext class) is only stored in renderable arrays, but not exposed to reverse proxies (or internal page context).
Introduce new Vary page response policy, that will tell reverse proxies how to properly cache returned responses. This proposal was originally raised in 🐛 Browser language detection is not cache aware Needs work , but moved to the new issue, as it solves a bigger problem.
@catch in https://www.drupal.org/project/drupal/issues/2430335#comment-12842970 🐛 Browser language detection is not cache aware Needs work argues against usage of vary header in core itself, but with all respect, I cannot agree - Vary is the standard HTTP way of informing proxies about cache contexts of the origin server, especially when the response varies depending on one or more HTTP headers. Vary header is here exactly for this purpose, so it seems natural to use it.
- Rewrite the patch from
https://www.drupal.org/project/drupal/issues/2430335#comment-12840473
🐛
Browser language detection is not cache aware
Needs work
, leaving only the part that introduces new response policy (and it's test)
- Modify the patch in
🐛
Browser language detection is not cache aware
Needs work
to only contain changes needed for browser language negotiation.
- No UI changes
- New page_cache_vary service that triggers adding Vary header
Major since it unblocks major bug 🐛 Browser language detection is not cache aware Needs work
Needs work
10.1 ✨
Last updated
It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Contrib blocker, see: #3222748-30: Create a page if given internal path is not valid →
Addressed point #14.2 of comment #14, keeping the status needs work for comment #14.1.
Any update on this issue?
Will this be included in core?