4xx Recursion issue on non-existent html routes

@malcolm_p, Thank you for reporting this problem. We rely on issue reports like this to improve Drupal core.

I tested this on 10.1.x, standard install, and was not able to reproduce this error. I followed the steps given in the Issue Summary.

Therefore, closing as outdated. If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue → (starting from "Install Drupal core").

Thanks!

Was unable to replicate this in a clean core install. Core will simply return a "A client error happened" response.

For me, it was triggered because another custom kernel.request event subscriber made a call to \Drupal\Core\Path\PathValidatorInterface::getUrlIfValid(), but didn't have any error handling in place, resulting in an infinite recursion.

A similar

    try {
      // ...
    }
    catch (ResourceNotFoundException $e) {
      $result = FALSE;
    }
    catch (ParamNotConvertedException $e) {
      $result = FALSE;
    }
    catch (AccessDeniedHttpException $e) {
      $result = FALSE;
    }
    catch (MethodNotAllowedException $e) {
      $result = FALSE;
    }

try catch used in \Drupal\system\PathBasedBreadcrumbBuilder::getRequestForPath() is also present in \Drupal\Core\Path\PathValidator::getPathAttributes(), so they're probably somewhat related.

I had this happen in Drupal 9.5.11. Sorry it's not the latest, but that's what I have currently and where it was triggered.

I've attached a sanitized backtrace showing where it loops. The inner block looped hundreds of times before running out of memory.

I've also attached a basic patch that uses a static integer to count how many times ParamNotConvertedException is thrown (and then just don't throw the exception if it's more than once).

For me, this specifically triggers on an invalid /node/## path, and when NOT logged in. I used the path /node/8675309, but any number that is not a node ID should trigger it as well.

I do hope someone can make sense of this information, and find the actual cause instead of my static int counter workaround.

This is a pretty serious bug, because we had a rogue web scraper hit HUNDREDS of bad /node/## pages, tying up all of our PHP processes, and essentially DDOS'ing our server for a little while.

I saw some infinite recursions in one of my projects and couldn't figure out what is going on until today. I am finally able to reproduce this problem and have an explanation for why it happens. And yes, it happens on a fresh installation, but it a (very small) customization for it to happen.

My particular case:
- Automated bots were hitting my website with drupalgeddon hacking attempts. This particular bot was POSTing on the homepage using these query params: name[post_render] and name[markup]. After sanitizing these inputs, drupal will delete everything and put an empty name[] array in the query parameter bag. All fine so far.
- As it happens, I also print a form on all pages (including 4xx) which does a very benign \Drupal::request()->query->get('name')
- Now adding these two non-issues together leads to an infinite loop, as follows: Drupal will redirect to a 404 page, thus making a subrequest to the 4xxController. My code will call query->get('name'), which will trigger an exception, because the empty array that exists in the query is a non-scalar (Symfony\Component\HttpFoundation\InputBag.php:38). Reading this value leads to a new exception which will render an error page, which will again try to read the value from the query, and on and on until it either runs out of memory or triggers a script timeout.

A general case:
- Inside a hook that runs on error pages too, such as a hook_preprocess_html, add the following: \Drupal::request()->query->get('name')
- Perform a request on any page, adding the query parameter without any value: ?name[]
- Watch it crash

@staalex I think this was fixed in 🐛 DefaultExceptionHtmlSubscriber should not clone the request for 401s Active can you double check with the latest patch release?

@catch absolutely, I wasn't aware of this core issue. I can confirm the patch fixes the issue (at least my case). Thank you.

Thanks for checking. I wasn't aware of this issue until a couple of days ago either. Closing as outdated.