The new router supports (or will support when it's all in place) different responses for the same uri based on accept headers. This is also the current design for the serialization work. However Drupal's page cache only caches by path, not accept headers.
Ideally we want to be able to do full caching in reverse proxies and/or the internal page cache regardless of the response (as you currently can for RSS albeit at a different path). We also don't want to serve incorrect responses if HTML gets in the page cache and it bypasses the routing system.
Throughout the comment chain below, we have identified the following proposed solutions:
@greg.1.anderson in comment #16 (improvement idea)
The cache key should contain a hash of the data type that was stored in the cache, not the set of all types that were requested. If someone used wget to request just "text/html", it would not make sense to generate a different cache key than the request shown for the browsers listed in #13.
This is hard because we haven't bootstrapped modules at the time the cache key is generated and checked.
If a module needs different "granularity" of normalization (e.g. to return a different type for "application/xhtml+xml" than for "text/html"), then it would need to somehow specify in some way that xhtml is significantly different than html, and this would have to happen on a path-specific basis.
@effulgentsia in comment #44
The reason [the patch in #42] fails is that formats are currently registered in KernelEvents::REQUEST subscribers, but currently, page cache is pre-kernel. Also mentioned in #1984766-3: Start relying on Request/Response objects for cache handling
1. getting the patch in #42 to work correctly and pass testing
2. from comment #9: "we start hosting a sane sample config on Drupal.org (if we don't already) and we can include well-documented normalization routines there"
3. from comment #9: "Make page caching work with accept header-based routing"
User interface changes
drupal_page_get_cache() has changed to take a Request object, the $check_only param was removed.
the Request object is required to build a page cache cid from
nothing in core used the $check_only flag.
- #339958: Cached pages returned in wrong language when browser language used
- #1944472: Add generic content handler for returning dialogs
- #1505080: [META] Content Negotiation for Accept Headers
- #1984766: Start relying on Request/Response objects for cache handling
- #1984766-3: Start relying on Request/Response objects for cache handling
Original report by catch
Additional info from original report, not included in summary:
Someone is bound to point out that there isin the queue, but I see no sign of HttpCache supporting this either, i.e.
<?php return $this->keyCache[$request] = 'md'.sha1($request->getUri()); ?>
Opening this as critical, however it might be postponed on this feature actually being implemented.
I'm not sure which issue it is that actually does this, there isbut this felt a bit off-topic in that issue. However if that's the one we could also just make sure that any patch that introduces this comes with tests to ensure this particular feature still works.
PASSED: [[SimpleTest]]: [MySQL] 58,021 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 57,920 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 57,992 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 57,644 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 57,944 pass(es), 1 fail(s), and 0 exception(s). View