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

Я нахожусь в процессе обновления 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


person Domagoj    schedule 11.07.2019    source источник
comment
Пожалуйста, предоставьте примеры определенных маршрутов и URL-адресов, которые вы используете, и если они действительно перенаправляются каким-либо образом.   -  person yivi    schedule 17.07.2019


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


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

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

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

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

person Arno Hilke    schedule 15.07.2019
comment
Вы знаете, когда это было введено? - person Domagoj; 18.07.2019
comment
Перенаправление с /foo на /foo/ всегда поддерживалось, другое направление было реализовано в Symfony 4.1. Источник: symfony.com/blog/new-in- symfony-4-1-smarter-url-redirections, PR: github.com/ symfony/symfony/pull/26283. В документации для версии 4.1 это также упоминается (symfony.com/ doc/4.1/). - person Arno Hilke; 18.07.2019