3

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

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

在不替换正确参数的情况下继续调试 3.4 项目。

我的问题是这现在是否是正确的请求流（即每条路由都必须通过 urlRedirectAction）并且我需要配置其他东西，或者有什么方法可以避免调用，我猜，RedirectableCompiledUrlMatcher？

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

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

4

1 回答 1

3

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

如果您有两个版本的路由定义，则将匹配第一个。如果您以其他方式使用 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 中的第 63 行GET /foo/所做的（即在示例 1 中）。如果路由可以完全匹配（即GET /foo在示例 1 中），则不应到达此重定向，并且匹配器应在第 39 行返回。

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

  1. 您是否依赖/foo并/foo/与众不同？使用默认匹配器将不再可能（对于 GET 或 HEAD 请求）。
  2. 你是要求/foo还是/foo/反之？这应该不是问题，但会导致重定向，可能会导致其他地方出现问题。

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

于 2019-07-15T19:54:25.847 回答