Re: нормализация uri
Maxim Dounin
mdounin на mdounin.ru
Пт Авг 14 14:27:29 UTC 2020
Hello!
On Fri, Aug 14, 2020 at 02:37:05PM +0300, Gena Makhomed wrote:
> Есть такая конфигурация:
>
> client <=> nginx-frontend <=> nginx-backend <=> php-fpm
>
> Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
> идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
> и чтобы точка в конце домена также убиралась с помощью 301 редиректа.
>
> Сейчас эту задачу можно решить только на стороне nginx-frontend
Никто не запрещает решать эту задачу на любых других уровнях, в
том числе в php. Другой вопрос, что если менять URI на строне
nginx'а (например, проксируя с заменой части URI) - исходный URI
придётся явно пробрасывать и отдельно обрабатывать.
> с помощью такого программирования на конфигах nginx для каждого
> виртуального сервера:
>
> # remove multiple sequences of forward slashes
> # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri
> # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop
> if ($request_uri ~ "^[^?]*?//") {
> rewrite "^" $scheme://$host$uri permanent;
> }
>
> if ($http_host ~ "\.$") {
> rewrite "^" $scheme://$host$uri permanent;
> }
Отмечу, что тут "напрограммировано на конфигах" два XSS'а.
Эту и другие подобные проблемы умеет, AFAIK, ловить
https://github.com/yandex/gixy.
> Хотелось бы избежать программирования на конфигах nginx-frontend
> и перенести всю логику нормализации урлов на сторону php-fpm,
> если это вообще теоретически возможно без дополнительного программирования и дополнительного оверхеда на стороне nginx-frontend,
См. выше, это выглядит как легко решаемая задача.
> или обойтись всего одной директивой в конфиге на уровне http {},
> например, merge_slashes redirect; или normalize_uri on;
>
> На одном физическом сервере несколько сотен виртуальных хостов,
> программирование на конфигах nginx делает конфиги трудночитаемыми,
> и есть стойкое ощущение, что это не самый оптимальный solution.
>
> Насколько высока вероятность того, что патч, реализующий
> дополнительную функциональность merge_slashes redirect;
> или normalize_uri on; будет принят в основную ветку nginx?
Задача не кажется типичной. Если очень хочется решать её силами
nginx'а - я бы рекомендовал начать с инкапсуляции нужных
перенаправленый в отдельных include-файлах, и/или решений на
скриптовых языках, или же отдельного модуля для нормализации.
--
Maxim Dounin
http://mdounin.ru/
Подробная информация о списке рассылки nginx-ru