maybe you already considered it, but a quick solution is to allow slashes in parameters, just by doing:

_some_route:
    path: /create/zip/{folder}
    defaults: { _controller: YourController }
    requirements:
        folder: .+

but of course you should put folder as last parameter.

You could also consider this:

_some_route:
    path: /create/{folder}
    defaults: { _controller: YourController }
    requirements:
        folder: .+

then generate your url with

path('_some_route', {'folder': '/home/user', 'format': 'zip'})

which will give you:

/create//home/user?format=zip

Why do you need {folder} in the path? Just make it a query param. Then you don't have this problem.
IMO there are 2 cases:

1. You want a user friendly URL and have the param in the path. In this case you also do not want to encode it.
2. It's not intended for users (e.g. API) which your path (/create/{folder}/zip) looks like. Then you can just use a query param or body param for that. Btw, having the verb (create) in the path is not best practice if that is for a REST API. You might want to use POST instead.

It's a REST API, and path in the main comment is just an example. Of course I use POST/GET e.t.c. for creation/update, not create path in the url.

There're many possible solution, but neither solve the main problem of "incorrect" url param encoding.
Currently I extended UrlGenerator class, to produce urls in format I need.

I don't consider possibility to move {folder} to get params or body, cause REST path structure assume that accessed resource name should be in the path not in the params, ex.:
GET /user/{username}/folder/{folder}/file/{filename}?search=asd

To @inmarelibero: you descriveb my first case, but this solution will produce incorrect urls for rest api.

Even when %2F is, strictly speaking, allowed in URLs, if it is disallowed in Apache and JBoss for security reasons, it makes it in practice disallowed, IMO. Apache is not just another marginal web server and Symfony cannot just say "let their users deal with the problem".

Anyways, could this be solved by adding a method setDecodedChars so you could override the default pairs of decodedChars?

That is not the fix I was hoping for.. but yes, that will help, thought not for current implementation of UrlGenerator class, it will incorrectly encode url because of code at line 192.

IMHO: There're way too many other web servers (nginx, tomcat, netty, jetty, e.t.c.), if someone introduced something stupid, it doesn't mean that others should support it. It's a bit strange to have advantage for 2 servers, and break compatibility with others. A specially with URI RFC.

P.S. That apache and jboss behavior is configurable.

Double URL encoding could be a security risk: https://www.owasp.org/index.php/Double_Encoding

Perhaps instead of

we can do the rawurlencode before we prepend to $url, and for each of them we can detect whether they're already URL-encoded (is that safe?) or best if the user can set an already_encoded flag for each parameter...

The strtr seems safe to be done only once at the current line.

Solutions proposed by @Tobion should be the way to go.

Let's close this old issue as "won't fix", since it's not a good practice to resolve parameters containing slashes.

Thanks.

I strongly disagree. A framework such as Synfomy should be able to handle and generate all kind of standard compliant URIs. If, for any reason, certain properly encoded characters should be forbidden in the path, this should be done by some configurable validation component. Given that this is not possible with the current UrlGenerator is a strong indication to rewrite the UrlGenerator.

2016.. The most popular php web framework, is not compatible with uri rfc (rfc3986).

What's the status of this? Are there any workarounds that don't require changes to the URL schema?