Option to disable the automatic 301 redirection without trailing slash #29011
Comments
|
I'm not sure the linked SO entry applies: the router doesn't redirect from https to http. And the top reply is right: you should fix your calls to send them to the correct URL. I'm not sure we should make the component more complex to support this option (I'm pretty sure we shouldn't actually ;) ) |
In my case it did, since the smyfony app was called from a reverse proxy via HTTP, but the connection to the client was HTTPS.
The reason I don't like it is the "magic" behaviour. If you don't randomly see the part of the documentation, there is no reason to expect this. Since the redirect is not logged anywhere, you might only realize if it breaks suddenly for whatever reason (AJAX calls, API clients which don't support a redirect, etc). |
|
The behavior makes sense to me for user facing URLs. That's why it's been added I suppose. |
|
Personally I don't like unexpected "magic" functions at all, in any case. For now I have used a compiler pass to revert to the "classic" UrlMatcher, but this is an ugly workaround. public function process(ContainerBuilder $container) {
$router = $container->getDefinition("router.default");
$options = $router->getArgument(2);
$options["matcher_class"] = 'Symfony\\Component\\Routing\\Matcher\\UrlMatcher';
$options["matcher_base_class"] = 'Symfony\\Component\\Routing\\Matcher\\UrlMatcher';
$router->setArgument(2, $options);
} |
Still, the request should be treated as secure by the application. Are you sure you properly configured the trusted hosts? |
Maybe I need to do some additional configuration on the Symfony side, but since the conenction from reverse proxy to symfony was "http", Symfony created a 301 redirect to "http://" which was not trusted by the client anymore. |
|
And that's why it's important to properly tell Symfony about the reverse proxy as the proxy will send a special header telling the application about the secure connection allowing Symfony to treat the request as if it was actually encrypted. |
|
I would personally be OK to consider deprecating the redirection when the |
|
Just to add some more insights for this issue. Here is another use case: we want to hide some part of the application using a reverse proxy. This means we proxy Depending on the proxy you use (basically: works with nginx, fails with haproxy) you may experiment redirection issue, because (and it's pretty logical) it transform |
|
IMHO, no real issue here as it is all infrastructure related problems. But it would be cool if one could opt-out from the trailing slash redirection for any reasons. |
|
I'm experiencing exactly what @Nek- described. My Symfony application returns a fully qualified redirect for the trailing slash and thus leads the user onto the origin server. The same happens for The problem might just be the fact that Symfony insists on fully qualifying the redirect which makes the whole thing a lot less flexible for this kind of scenario. |
|
Also noticed this as it brokes some tests in one of my application. But they were redirections tests, so it's wasn't a problem as the final destination URL was correct. |
|
Adding an optional parameter in the configuration would really add complexity? It would kind of keep the backward compatibility with some existing projects. |
|
I completely lost here: automatic redirection as described in the original description is expected and exists since early versions of the router component (before 2.3). |
|
As an addition to the CompilerPass solution by @arneee , which I used - for Symfony 4.3 it does not work anymore because of changes to the Routing component, so it needs to be modified to use public function process(ContainerBuilder $container): void
{
$router = $container->getDefinition("router.default");
$options = $router->getArgument(2);
$options['matcher_class'] = CompiledUrlMatcher::class;
$router->setArgument(2, $options);
}Maybe that helps others to avoid my headaches of finding a solution ;-) |
I also have the issue that I get 301 redirect from https to http did anyone manage to sort it out? |
Description
This is a "magic" behaviour which can be unwanted in certain cases. For example it can break AJAX calls via HTTPS.
There should be an option to disable this behaviour and enforcing strict URL matching on the route, without any magic redirects behind.
The text was updated successfully, but these errors were encountered: