Problem/Motivation

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

Proposed resolution

Add some flag on the route in order to indicate that.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

fabianx’s picture

Status: Active » Postponed (maintainer needs more info)

There is a no_cache: 1 flag on routes already.

Does that not work?

wim leers’s picture

#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: TRUE set.

dawehner’s picture

At first sight, I think it makes sense for the wrapping subscriber to never throw exceptions for routes that have no_cache: TRUE set.

That is not a bad idea, true.

plach’s picture

At first sight, I think it makes sense for the wrapping subscriber to never throw exceptions for routes that have no_cache: TRUE set.

+1

fabianx’s picture

Why would you return a cacheable response when you set the route to no cache?

dawehner’s picture

Why would you return a cacheable response when you set the route to no cache?

This is why REST requests should

not

set no_cache .

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joelpittet’s picture

Version: 8.1.x-dev » 8.2.x-dev
Status: Postponed (maintainer needs more info) » Active

Bumping this to get a decision, seems kinda more related to 'routing system' or 'cache system', no?

dawehner’s picture

Well yeah its maybe also the request processing system ...

OT while thinking about this class: #2721191: Consider moving event subscribers to their components

joelpittet’s picture

Component: render system » routing system

Since the proposal in the issue summary is to change the route, I'll move it there. Seems slightly more directed at what may change...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

roderik’s picture

Why would you return a cacheable response when you set the route to no cache?

Because Drupal kind-of forces you to - at least when needing to redirect to an external URL.

RedirectResponseSubscriber contains:

      if (!($response instanceof SecuredRedirectResponse)) {
        try {
          // SecuredRedirectResponse is an abstract class that requires a
          // concrete implementation. Default to LocalRedirectResponse, which
          // considers only redirects to within the same site as safe.
          $safe_response = LocalRedirectResponse::createFromRedirectResponse($response);
          $safe_response->setRequestContext($this->requestContext);
        }
        catch (\InvalidArgumentException $e) {
          // If the above failed, it's because the redirect target wasn't
          // local. Do not follow that redirect. Display an error message
          // instead. We're already catching one exception, so trigger_error()
          // rather than throw another one.
          // We don't throw an exception, because this is a client error rather than a
          // server error.
          $message = 'Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.';
          trigger_error($message, E_USER_ERROR);
          $safe_response = new Response($message, 400);
        }
        $event->setResponse($safe_response);
      }

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:

  1. Use a TrustedRedirectResponse, and set 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.
  2. Implement your own response object that implements SecuredRedirectResponse but not CacheableSecuredRedirectResponse - basically copying the TrustedRedirectResponse contents into a new class. (I am just now, while typing this up, realising this is even an option. The forest of Response objects and related event subscribers isn't easy to find your way around. So I don't think many people have done this.)

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...)

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

solideogloria’s picture

This would be super helpful to have when using external redirects.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.