Проблема маршрутизации Symfony 4.3 - каждый маршрут соответствует urlRedirectAction - PullRequest
Новая
       35

Проблема маршрутизации Symfony 4.3 - каждый маршрут соответствует urlRedirectAction

4 голосов
/ 11 июля 2019

Я нахожусь в процессе обновления Symfony с 3.4 до 4.3, и у меня есть ситуация, в которой каждый маршрут корректно сопоставляется с контроллером и методом, но затем запрос достигает RedirectableCompiledUrlMatcher и заменяет правильные параметры на _controller: Symfony\Bundle\FrameworkBundle\Controller\RedirectController::urlRedirectAction

Это вызывает все виды других вещей, таких как вызов преобразователей параметров, попадание в брандмауэры и другие вещи, связанные с маршрутизацией, которые не должны выполняться, потому что соответствующий маршрут не является правильным.

Отладка проекта 3.4 продолжается без замены правильных параметров.

Мой вопрос заключается в том, является ли это теперь правильным потоком запросов (т. Е. Каждый маршрут должен проходить через urlRedirectAction), и мне нужно настроить другие вещи, или я могу как-нибудь избежать вызова, я думаю, RedirectableCompiledUrlMatcher?

Возможно ли, что это происходит, потому что RedirectableUrlMatcher является сопоставителем по умолчанию для \Symfony\Component\Routing\Router, и почему он является сопоставлением по умолчанию?Любой шанс заменить это на обычный UrlMatcher, как это есть в 3.4?

Это именно эта строка vendor/symfony/routing/Matcher/Dumper/CompiledUrlMatcherTrait.php:63, где у меня $ret правильно соответствует моему контроллеру и вызывается $this->redirect(), который заменяетмой контроллер с Symfony RedirectController.Черта является частью RedirectableCompiledUrlMatcher класса

1 Ответ

2 голосов
/ 15 июля 2019

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/ будет совпадать нормально.

Thisредирект для отсутствующей / дополнительной конечной косой черты - это то, что делает строка 63 в CompiledUrlMatcherTrait (т. е. GET /foo/ в примере 1). Если маршрут может точно совпадать (т. е. GET /foo в примере 1), это перенаправлениене должно быть достигнуто, и сопоставитель должен вернуться в строке 39 .

Так что для вашей конкретной конфигурации маршрутизации, вопросы:

  1. Вы полагаетесь на /foo и /foo/быть другим?Это не будет возможно при использовании сопоставления по умолчанию (для запросов GET или HEAD).
  2. Вы запрашиваете /foo с /foo/ или наоборот?Это не должно быть проблемой, но вызывает перенаправление, которое может вызвать проблемы где-то еще.

Если проблема остается, предоставьте соответствующую выдержку из вашей конфигурации маршрутизации с примером запрошенного и перенаправленного URL.

...