Problem/Motivation
Since #2481453: Implement query parameter based content negotiation as alternative to extensions, any controller returning a render array may be rendered in multiple wrapper formats.
This means that the response for the controller varies by the 'url.query_args:' . MainContentViewSubscriber::WRAPPER_FORMAT
cache context.
Proposed resolution
Ensure that the 'url.query_args:' . MainContentViewSubscriber::WRAPPER_FORMAT
cache context is present for any response that is rendered by MainContentViewSubscriber
, because MainContentViewSubscriber
renders it in a different wrapper format depending on that URL query argument.
Remaining tasks
Review.
User interface changes
None.
API changes
None.
Data model changes
None.
Beta phase evaluation
Issue category | Bug because this breaks cacheability of responses. |
---|---|
Issue priority | Major because it blocks significant other issues. |
Prioritized changes | The main goal of this issue is performance/cacheability. |
Disruption | Zero disruption. |
Comment | File | Size | Author |
---|---|---|---|
#17 | wrapper_format_url_query_argcache_context-2552013-17.patch | 22.92 KB | Wim Leers |
Comments
Comment #2
Wim LeersComment #3
dawehnerQuestion: So we need to not change that many places, because we use url.query_args in other places already?
Comment #4
Wim LeersYes, or
url
.url
impliesurl.*
, i.e.url.query_args
,url.query_args:foo
, et cetera. See https://www.drupal.org/developing/api/8/cache/contexts#optimizingComment #5
dawehnerDo we need some explicit test coverage for this issue? I mean adding the expected cache contexts is one thing, but having a real case is another.
Comment #6
Wim LeersGreat question!
I'd say:
— but… we only set theX-Drupal-Cache-Contexts
header forCacheableResponseInterface
responses. And… onlyHtmlResponse
implements that. NotAjaxResponse
(which is what AJAX/dialog/modal all use). So we cannot actually test this. AFAICT this is also why #2472323: Move modal / dialog to query parameters didn't introduce test coverage for this.So… not sure what to do. Ideas? It feels like this patch's test coverage updates are sufficient for now, until other wrapper formats have cacheable responses?
Comment #7
dawehnerTo be honest it feels like the code could still be broken in theory now after reading your latest comment. We could for sure write a test wrapper which implements the
CacheableResponseInterface
Comment #8
Wim LeersOk, let's do that.
Comment #9
borisson_#2476407: Use CacheableResponseInterface to determine which responses should be cached will also introduce a
CacheableJsonResponse
that also implementsCacheableResponseInterface
. So adding a test could be a followup to that issue?Comment #10
Wim Leers#9: but we still won't be able to render a render array into a JSON response. Except, of course, we could do that for testing purposes. We'd have to come up with a fairly silly wrapper format anyway.
How about this: I'll adopt the
CacheableJsonResponse
class from the patch over there in this patch, and whichever patch lands first then makes the other patch smaller :)Comment #11
Wim LeersEt voilà.
Comment #13
Wim LeersThis too is failing with the same random fails: #2552687: Test failures in ConfigFormOverrideTest and ContainerRebuildWebTest on newly spun up testbot instances.
Comment #14
Wim LeersComment #16
dawehnerIf we would have missed that cache context we would have served the wrong kind of context, therefore I think we should have an integration test coverage
which ensures that you can cache two different wrapper formats and get different output.
Comment #17
Wim Leersd'oh, of course!
Comment #20
Wim LeersComment #21
dawehnerCool. Thank you!
Comment #22
catchCommitted/pushed to 8.0.x, thanks!