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