Query parameters are not decoded the same as the path portion of a URL

So why the fuck is nobody able to open up an issue against symfony?

+++ b/core/lib/Drupal/Core/Routing/UrlGenerator.php
@@ -122,6 +122,10 @@ protected function getInternalPathFromRoute(SymfonyRoute $route, $parameters = a
+      list($path, $query) = explode('?', $path);

Can we ensure to use explode(' ..., 2) as always?

If I understand the upstream issue correctly:

- doGenerate() does too much in one method, so we can't easily override just part of it to do this.

- It's unclear if Symfony would consider escaping additional characters in the query parameters to be an API break. (I wouldn't consider it one but Symfony has a tighter BC policy than Drupal at the moment.)

- This is mostly a cosmetic issue, making query parameters actually readable by humans. It shouldn't impact the actual executability of code.

That means our options are:

1) Just do it ourselves post-generate (aka, #5. Easy but a but fugly.)

2) Refactor doGenerate() upstream so that we can override just a bit of it to do whatever escaping we need. (ie, break it into a series of methods; that should be entirely safe from a BC perspective.)

3) Modify doGenerate() upstream to also escape query parameters, if Symfony permits.

I think it's best on this one to defer to upstream. I've pinged fabpot and lsmith for their recommendation on how to proceed.

Is there a link to an upstream issue?

Well, as always, just a few people actually try to fill these upstream issues: https://github.com/symfony/symfony/issues/12200

@tim.plunkett
As someone mentioned on the symfony issue, we cannot escape most of the characters but can only do '?' and '/' which is already enough for our cases.
For example '[' and ']' introduces regressions of arrays in query arguments.

Let's mark i actually as postponed on the symfony issue.

https://github.com/symfony/symfony/issues/12200 got merged - anything needed here other than a Symfony update now?

@catch
This just got merged into master, so it will be available once 2.6 is released which will be quite time soon. I think its not worth to go to master
just because of that.

OK I opened #2366043: Upgrade to Symfony 2.6.0-beta1, let's mark this postponed - if there's a good reason to patch or go to master prior to 2.6, we can re-open for that.

That update was committed, so back to needs work?

I think it's just a case of committing the tests here now.

Assuming it passes...

+1

Changed category and priority to reflect what the patch is actually doing. This issue is a prioritized change (adding tests) as per https://www.drupal.org/core/beta-changes and it's benefits outweigh any disruption. Committed fd63394 and pushed to 8.0.x. Thanks!