Question

我正在将Symfony从3.4升级到4.3，并且遇到以下情况：每条路由都与控制器和方法正确匹配，但是请求到达RedirectableCompiledUrlMatcher并用替换正确的参数 _controller: Symfony\Bundle\FrameworkBundle\Controller\RedirectController::urlRedirectAction

这会触发各种各样的其他事情，例如调用参数转换器，击中防火墙以及其他与路由相关的事情，这是不应该的，因为匹配的路由不正确。

调试3.4项目将继续进行，而不会替换正确的参数。

我的问题是，现在这是否是正确的请求流（即，每个路由都必须通过urlRedirectAction），并且我需要配置其他内容，还是有什么办法可以避免调用RedirectableCompiledUrlMatcher？< / p>

是否可能发生这种情况，因为RedirectableUrlMatcher是\Symfony\Component\Routing\Router的默认匹配器，为什么它是默认匹配器？是否有机会像3.4中那样用普通的UrlMatcher替换它？

正是在这行vendor/symfony/routing/Matcher/Dumper/CompiledUrlMatcherTrait.php:63中，我已经将$ret与控制器正确匹配，并且正在调用$this->redirect()，用Symfony RedirectController替换了我的控制器。特质是RedirectableCompiledUrlMatcher类的一部分

Answer 1

Symfony 4更改了路由，因此对于GET和HEAD请求（参见https://symfony.com/doc/4.3/routing.html#redirecting-urls-with-trailing-slashes），带斜杠的路由被认为等同于不带斜杠的路由。

如果两个版本都有路由定义，则第一个将匹配。如果您以其他方式使用它，则RedirectableUrlMatcherInterface将创建到该路由的重定向。

示例1

# routes.yaml
foo:
  path: /foo
  controller: App\Controller\FooController::fooAction

foo_trail:
  path: /foo/
  controller: App\Controller\FooController::fooAction

GET /foo/将重定向到GET /foo，GET /foo将正常匹配。

示例2

# routes.yaml
foo_trail:
  path: /foo/
  controller: App\Controller\FooController::fooAction

foo:
  path: /foo
  controller: App\Controller\FooController::fooAction

GET /foo将重定向到GET /foo/，GET /foo/将正常匹配。

针对丢失/其他尾部斜杠的重定向是CompiledUrlMatcherTrait中的line 63所做的操作（即示例1中的GET /foo/）。如果路由可以完全匹配（例如示例1中的GET /foo），则不应达到此重定向，匹配器应在line 39中返回。

对于您的特定路由配置，问题是：

您依靠/foo和/foo/有所不同吗？默认匹配器（对于GET或HEAD请求）将不再可能。
您要与/foo一起使用/foo/吗？反之亦然？这不应该是问题，但是会导致重定向，而重定向可能在其他地方引起问题。

如果问题仍然存在，请提供路由配置的相关摘录，并提供请求和重定向URL的示例。

Symfony 4.3路由问题-每个与urlRedirectAction匹配的路由

1 个答案:

示例1

示例2