An update to symfony/http-foundation plus a trailing space took down the views UI

Confirmed this also happens on Drupal 11 with version 7.1.7 of symfony/http-foundation.

was this included in the Drupal 10.3.7 release because now all of my views and search API displays are borked throwing this error.

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid URI: A URI must not start nor end with ASCII control characters or spaces.

Bumping to critical.

Facing the same issue with the views admin page. Downgrading symfony/http-foundation to 6.4.12 makes the error go away. Not sure what will be the reliable fix for the issue.

We already trim the path on updating the path - see \Drupal\views\Plugin\views\display\PathPluginBase::validateOptionsForm() - so it'd be interesting to know how the space got into the path in the first place. Could people confirm if these has occurred on sites that have been migrated from Drupal 7 or do the views use a different plugin that provides a path?

If you are affected by this issue, are you able to provide a config export of the view?

I've tried to recreate this bug on Drupal 11. Here are the steps I've followed:

1. Install Standard profile
2. Duplicate the comment views
3. Export config
4. Edit the duplicate view to have paths with a space on the end
5. Import config
6. Visit views UI listing... no crash and can see URLs with spaces on the end in the UI. They don't work and but you can't enter these urls via the UI so I think that that is okay.

What I am missing?

One of the views has a URL ending with a space. I used ctrl+F on pattern "[space])" to find the occurrence.

See the screenshot below,

Seems like it was configured incorrectly in the first place.

Implemented @longwave's suggestion. I guess we could use a test.

Note that the router entry for a view (even a REST view with a space on the end is fine because this is fixed in \Symfony\Component\Routing\Route::setPath()

Extended the existing XssTest to use a view with a path containing a space, as well as the listing page the view edit page also has the same bug which the test found for me.

The test is not going to fail until we update Symfony but running locally I can confirm it fails as expected.

./vendor/bin/phpunit  core/modules/views_ui/tests/src/Functional/XssTest.php
PHPUnit 10.5.38 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.3.12
Configuration: /Volumes/dev/sites/drupal8alt.dev/phpunit.xml

FF                                                                  2 / 2 (100%)

Time: 00:21.394, Memory: 10.00 MB

--

There were 2 failures:

1) Drupal\Tests\views_ui\Functional\XssTest::testViewsUi
Behat\Mink\Exception\ExpectationException: The string "<marquee>test</marquee>" was not found anywhere in the HTML response of the current page.

/Volumes/dev/sites/drupal8alt.dev/vendor/behat/mink/src/WebAssert.php:888
/Volumes/dev/sites/drupal8alt.dev/vendor/behat/mink/src/WebAssert.php:363
/Volumes/dev/sites/drupal8alt.dev/core/tests/Drupal/Tests/WebAssert.php:558
/Volumes/dev/sites/drupal8alt.dev/core/tests/Drupal/Tests/WebAssert.php:546
/Volumes/dev/sites/drupal8alt.dev/core/modules/views_ui/tests/src/Functional/XssTest.php:27

2) Drupal\Tests\views_ui\Functional\XssTest::testNoDoubleEscaping
Behat\Mink\Exception\ResponseTextException: The text "sa_contrib_2013_035" was not found anywhere in the text of the current page.

/Volumes/dev/sites/drupal8alt.dev/vendor/behat/mink/src/WebAssert.php:907
/Volumes/dev/sites/drupal8alt.dev/vendor/behat/mink/src/WebAssert.php:293
/Volumes/dev/sites/drupal8alt.dev/core/tests/Drupal/Tests/WebAssert.php:979
/Volumes/dev/sites/drupal8alt.dev/core/modules/views_ui/tests/src/Functional/XssTest.php:40

Committed/pushed to 11.x and cherry-picked to 11.1.x, thanks!

This doesn't cherry-pick cleanly to 10.x but I think we might want a backport?

We cleaned up unused variables in 11 but didn't backport that to 10.

Thanks new branch looks good - went ahead and committed that to 11.0.x and cherry-picked back through to 10.3.x, thanks!

catch → closed merge request !10140

catch → closed merge request !10138

Thank you @longwave, @catch, and @alexpott for fixing it so quickly.

Wow, what an edge case! 😄

I am still getting this on the home page which is configured with: /node
No blanks before or after.
D10.3.8

The /node only contains blocks configured via the block layout.
None of them has a path.
but all the blocks names are None.

Could that be related?
What do I need to look for?
Could we add a warning to the log IF the new patch finds an invalid character in one of the paths so one can identify the problem any better.

@maxilein this is likely slightly a different problem, please open a new issue with a full stack trace of the error, and if you think it is related to a view then a YAML export of the view would help too.

Thank you longwave. I tracked it down to a very similar issue with blanks in parameters. I mention this here in case it helps anybody else. it was hard to track down for me.

If your view uses a viewfield with blanks in calling parameters D10.3.8 seems to handle it differently than before. This patch made my Frontpage with its views come back: https://www.drupal.org/project/viewfield/issues/3470363 🐛 Contents of Viewfield - Arguments can cause unhandled PHP Errors Active

I have this issue after upgrading to 10.3.9, I don't see any spaces in my views URLs on the main views admin page.

After the update one particular views node display is no longer rendering and seems to be the cause of the client error. It uses a contextual filter "content id from URL" which in turn uses a relationship. There is no page display in the view.

There are no spaces in the URL of the node.

I also had this problem on blocks.
My viewfields were all blocks.
I created URLS using twig and they only had trailing spaces.

See this issue: https://www.drupal.org/project/viewfield/issues/3487798 🐛 WSOD after upgrade to D10.3.8 on views using entities with viewfields Active

With appreciation for the work on this, I've just tested this by upgrading to Drupal 10.3.x-dev from November 21st but the problem still persists.

To re-iterate, my case does not involve a space in a URL, it is triggered by views block displays that use a contextual filter on URL (raw value/content id, etc).

The display doesn't contain a page display. Removing all views blocks from the page returns the page again.

I'm unable to update to the latest security release due to this issue.

@alfthecat Your issue is not the same as the one described here, although the end result is the same. Please open a new issue, and include a config export of a view that demonstrates the problem.

In my case, the site continues to work fine, but whenever I clear Drupal cache, I get the following error:

Symfony\Component\HttpFoundation\Exception\BadRequestException: Invalid URI: A URI must not start nor end with ASCII control characters or spaces. in Symfony\Component\HttpFoundation\Request::create() (line 371 of /var/www/vendor/symfony/http-foundation/Request.php).

Is it somehow related to the bug reported here?

@longwave thanks, I opened 🐛 Drupal core update + update to symfony/http-foundation causes certain views blocks to cause a "client error" and breaks page display. Active .

Tagging needs followup because I'm not sure work here is complete. The Drupal\Core\Url methods are not actually documented to return a BadRequestException. Either this exception shouldn't be thrown, or should be caught and re-thrown as a different exception, or should be documented.

I created a patch based on the work that was done in the issue that is shared in comment #44 which fixes error handling for 10.3.x on my end.

Hello @ericpoir,
Thank you for your first patch ( 3486195-46.patch → ) which seams to suit to my use case, when running drush updb after updating to Drupal 10.3.10: the messages at the end of updb is "

[error] Symfony\Component\HttpFoundation\Exception\BadRequestException: Invalid URI: A URI must not start nor end with ASCII control characters or spaces. in Symfony\Component\HttpFoundation\Request::create() (line 365 of /var/www/html/vendor/symfony/http-foundation/Request.php).

"
Regards.

The patch in #46 fixes the issue for me as well.

Thanks!

Confirming, #46 works for me, too.

Thank you for the fix ! Works for me. #46

Patch in #46 appears to fix the issue for my install. Using 10.3.10.

The changes in the patch #46 seems to be available in 10.4.0 now.

Automatically closed - issue fixed for 2 weeks with no activity.

I had an issue with the edit forms, sometimes I would get this error too. I know it is not the same issue, but the patch in #46 fixed my issue. Is this going to be added anytime soon? I am on Drupal 10.3. Thanks.

We encountered an issue where a view using faceted filters triggered an error during an AJAX request. The error seemed related to invalid paths, but it only occurred once, and we have not been able to reproduce it since.
The error we noticed was:
Noticed exception 'Symfony\Component\HttpKernel\Exception\BadRequestHttpException' with message 'Invalid URI: A URI must not start nor end with ASCII control characters or spaces.' in /var/www/html/vendor/symfony/http-kernel/HttpKernel.php:83

Could this issue be related to the problem addressed by this patch? If so, would applying this patch be a good preventive measure to avoid similar events in the future?

Any guidance would be greatly appreciated.

@safoora_mir I believe the error is thrown in search faceted if your filter text or someone's text includes a trailing space. I was able to recreate it with a trailing space.

@safoora_mir I can confirm the issue.
I have the same error when I put a whitespace or a string that ends with a whitespace as a view parameter with AJAX that uses a facet search box of a facet source that uses the URL Processor Query string.

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid URI: A URI must not start nor end with ASCII control characters or spaces. in Symfony\Component\HttpKernel\HttpKernel->handle() (line 83