Active
Project:
Drupal core
Version:
main
Component:
routing system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
7 Jul 2015 at 23:37 UTC
Updated:
1 Mar 2023 at 22:45 UTC
Jump to comment: Most recent
I would argue that for the majority of pages you don't actually don't need caching.
One example are some admin pages, therefore it would be nice to just opt out of the cacheablity and ignore it
Add some flag on the route in order to indicate that.
Comments
Comment #1
fabianx commentedThere is a no_cache: 1 flag on routes already.
Does that not work?
Comment #2
wim leers#1: yes, but dawehner is referring to
\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.At first sight, I think it makes sense for the wrapping subscriber to never throw exceptions for routes that have
no_cache: TRUEset.Comment #3
dawehnerThat is not a bad idea, true.
Comment #4
plach+1
Comment #5
fabianx commentedWhy would you return a cacheable response when you set the route to no cache?
Comment #6
dawehnerThis is why REST requests should
not
set
no_cache.Comment #8
joelpittetBumping this to get a decision, seems kinda more related to 'routing system' or 'cache system', no?
Comment #9
dawehnerWell yeah its maybe also the request processing system ...
OT while thinking about this class: #2721191: Consider moving event subscribers to their components
Comment #10
joelpittetSince the proposal in the issue summary is to change the route, I'll move it there. Seems slightly more directed at what may change...
Comment #20
roderikBecause Drupal kind-of forces you to - at least when needing to redirect to an external URL.
RedirectResponseSubscriber contains:
So if you're a module that needs to do some processing and redirect somewhere else (e.g. Payment, SAML SSO), the only choices you have are:
no_cache: TRUE- not realising yet that you're falling into days of debugging "leaked metadata" exceptions at the moment someone e.g. enables some content access module.As a result, I think it's a pretty safe bet that the majority of people who have had to use external redirects in their code, have been doing exhausting debug sessions in the past 5 years.
... Anyway. Just as an FYI response. I don't have anything useful to add yet.
I wish I'd known this issue existed in 2019 when I was re-re-diving into URL issues. I was working up the confidence to propose this myself, but didn't have the background to know if it would make sense, and got lost into working on a related issue.
Maybe this spring...)
Comment #25
solideogloria commentedThis would be super helpful to have when using external redirects.