Igor Sysoev wrote:
On Thu, 22 Sep 2005, Alexander Gnevshev wrote:
Чтобы:
- была возможность избавиться от страниц-дублей;
Где - на сайте или в ссылках ?
Везде. В том числе в поисковиках.
А что это даёт, кроме лишнего запроса клиенту ? Веб переделать нереально.
Ты считаешь, что если кто-то поставил ссылку /dir, а сервер выдал
на неё редирект /dir/, то этот кто-то озаботится исправлением этой ссылки
у себя ? Сильно сомневаюсь.
Что касается поисковиков, то они индексы обновляют регулярно, достаточно
исправить у себя.
- всегда твёрдо знать, что параметры URI в
location сравниваются напрямую с URI, пришедшим
от пользователя (без преобразований);
Ну, например, частный случай: /page.html и //page.html. Что
предлагается
делать со вторым ?
Оставлять как есть и обрабатывать все location как есть, даже если это
вызовет 404.
А что делать /.././/./%2E%2E/../etc/passwd ?
- иметь полный контроль над URI, чтобы можно было
хотя бы в логе увидеть подобные запросы;
%request пишет в лог оригинальный URI.
Это значит, что при подсчёте статистики будет некоторая погрешность, так
как никто никогда не делает обработку a-la shell для директорий в URI при
обработке логов.
А вот это напрасно. Я в логах неоднократно видел /~user/ и /%7Euser/.
- не навязывать администраторам nginx парсинг URI
без возможности его отключения.
А как же URI обратывать, если его не парсить ? Как его потом
сравнивать с location ?
Под парсингом в данном случае я имел в виду автоматические замены для
каталогов:
* два и более слэша преобразуются в один слэш: "//" - "/";
* убираются ссылки на текущий каталог: "/./" - "/";
* убираются ссылки на предыдущий каталог: "/dir/../" - "/".
Вообще в наше время считать, что URI является прямым отображением на
директории на диске, -- прямая ошибка. Это уже давно не актуально. На
большинстве крупных ресурсов URI внутри обрабатывается (переписывается
rewrite и пр.) и с именем файла не совпадает.
Также очень интересен вариант, когда в URI передаётся параметр для
редиректа на другой сайт (двойной слэш). Так тоже делают, но этот вариант
не будет работать с nignx.
Именно поэтому очень хочется иметь возможность влиять на поведение nginx
в этом вопросе.
Ну вот пусть бэкенд и разбирается со странными URI, возможность передать
в оригинальном виде есть.
Игорь Сысоев
