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

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

Google search says "No, a URL cannot end with a space". Could be a loose input validation of views?

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 11.0.x or 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!

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

Sorry please ignore. I made a mistake.

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

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 views involved don'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 #3489329: symfony/http-foundation commit 32310ff breaks PathValidator.

Tagging needs followup because I'm not sure work here is complete. The Drupal\Core\Url methods are not actually documented to throw 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.

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. I upgraded to Drupal 10.4.1 and the issue was fixed as well.

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

Facing exactly same issue for facet. What was the fix suggested?

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