Some of the tests for FrameworkBundle are failing on PHP 7, because the tests assumes the changes made to symfony/routing by this PR, but Travis installs latest released version of symfony/routing. I can bump the requirement in composer.json, or I can make the code and tests compatible with both versions. How do we usually deal with this?

@MacDada Thanks for the review. I have addresses all your comments.

I still need some advice on the FrameworkBundle issue mentioned above.

I think there is a mismatch is the definition of the$charset params:
URLs have no encoding. HTML5 says that they should be encoded in UTF-8, and that when an non-valid UTF-8 URL is found, it should be converted from CP1252 by default.

-> we need a parameter to configure this fallback input charset. This can't be kernel.charset by default, but CP1252.

Then there is the output encoding of the URLs we generate. These should match the output encoding the app is using.

-> this matches the definition of the kernel.charset parameter so it can be injected here.

• Let's say I build an UTF-8 app in Russia => kernel.charset is UTF-8 and fallback input enc is some cyrillic enc.
• Let's now say I build a cyrillic app in Russia => kernel.charset is this cyrillic enc, and the fallback enc should also be kernel.charset (and we should still handle UTF-8 URLs as input of course).

URLs have no encoding.

True, a final URL has no encoding. The charset is used when we want to represent a non-ASCII character. For example, the Wikipedia article about the letter É has the URLhttps://en.wikipedia.org/wiki/%C3%89.%C3%89 is the percent-encoding of the two bytes representing É in UTF-8.

If ISO-8859-1 was used note (that was very common years ago), the URL would have beenhttps://en.wikipedia.org/wiki/%C9 (that URL currently redirects to the UTF-8-encoded one). Nowadays UTF-8 is the standard, and when accessing a UTF-8-encoded URL, the browser displayshttps://en.wikipedia.org/wiki/É in the URL field.

HTML5 says that they should be encoded in UTF-8, and that when an non-valid UTF-8 URL is found, it should be converted from CP1252 by default.

That rule only comes into play if the HTML contains URLs containing characters that are not properly percent-encoded. Such URLs are not valid and should never occur in HTML generated by Symfony functions.

However, since browsers prefer UTF-8 in the URL, I guess you would probably prefer to use UTF-8 as$router->charset even when kernel.charset is cyrillic. So I guess that default the router charset tokernel.charset is a bad idea.

That rule only comes into play if the HTML contains URLs containing characters that are not properly percent-encoded.

Not at all in my understanding, and in fact you cited what I meant: typehttps://en.wikipedia.org/wiki/%C9 in the browser, and get redirected to UTF-8,in the same way than HTML5 says (not the redirection but the charset conversion).

I guess that default the router charset to kernel.charset is a bad idea.

Yep, we need a fallbak input charset

Which part of the HTML5 spec are you referring to?

I guess we could implement a fallback encoding that automatically redirects like Wikipedia does, but I think that is a new feature that is outside the scope of this PR.

Which part of the HTML5 spec are you referring to?

an older draft one looks like, I can't find the reference :)

I tried an alternative approach in#19604
If#19604 looks good, it means we will have to work on another PR for charset reconciliation between incoming URLs and the charset used in the matcher. To me, this other PR doesn't necessarily belong to the router.We could just have a listener that comes before the router, checks the charset of the URL and either redirects, 404 or converts (the 3 strategies are valid to me, choice should belong to the dev). Unicode normalization could be also done in this listener (if we want it: it's costly, and we lived without for years, could be opt-in only).

@c960657 OK to close this one in favor of#19604?

Yes, let’s continue in#19604.