Как установить nginx URI для исправления пустого URI в перенаправлении на именованное местоположение

Как установить nginx URI для исправления пустого URI в перенаправлении на именованное местоположение

08.11.2016 09:42:27 Просмотров 57 Источник

Проблема: при доступе к нашему веб-сайту с недопустимым URL-адресом, который содержит знак"%", Nginx выдает ошибку 400 Bad Request.

Вместо страницы Nginx мы хотели бы переписать запрос на страницу (WordPress) 404.

Я пробовал следующее:

location @400 {
    rewrite ^ /404 break;
}

error_page 400 =307 @400;

Однако это создает 500 внутренних ошибок сервера на Nginx.

Журнал ошибок Nginx говорит:'... пустой URI в перенаправлении в именованное расположение "@400 " при чтении строки запроса клиента..., запрос:"GET <invalid-url>"'.

Это не является неожиданным, так как исходный URL-адрес является недопустимым.

Поэтому я думаю, что я ищу, чтобы установить URI явно для перезаписи. Как это сделать? Или есть лучший подход? Я не так хорошо знаком с Nginx.

У вопроса есть решение - Посмотреть?

Ответы - Как установить nginx URI для исправления пустого URI в перенаправлении на именованное местоположение / How to set Nginx URI to fix empty URI in redirect to named location

David

12.01.2019 12:25:59

Согласно документации код должен быть немного другим.

Это переписывание скопировано из документации:

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

Вопрос в том, будет ли это работать так:

location 400 {
    error_page 400 =307 http:/example.com/400.html;
}

... потому что на github-странице, которую вы связали, написано:

Если в конфигурации используется что-то вроде "error_page 400 @name", то запрос может быть передан в именованное расположение без набора URI, и это в свою очередь это может привести к ошибкам сегментации или другим негативным последствиям большая часть кода предполагает, что URI установлен.

С этим изменением nginx будет ловить такие проблемы конфигурации в ngx_http_named_location() и остановит обработку запроса, если URI не установлен, возвращая 500.

Если это все еще текущее состояние, это будет означать, что 400 триггеров ошибки в nginx ошибка 500. Тем не менее я мог бы вызвать ошибку 400 и также доставить пользовательскую страницу 400 только с этой конфигурацией:

error_page 400 /400.html;

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

Вы можете просто попробовать его с этой конфигурацией

error_page 400 /400.html;
error_page 404 /404.html;
error_page 500 /500.html;

Если это работает, вы можете настроить код 3xx и больше, как вы этого хотите. Конечно, вы также можете доставить страницу ошибки 404 на ошибку 400, но мне никогда не удавалось переписать заголовки ошибок, как это:

error_page 404 =301 http:/example.com/new/path.html;
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95154129_54154259
Не совсем тот ответ, который я искал,но все же ответ, который искал ОП.
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95154260_54154259
То, что я пытался сделать, - это вернуть 444 (close connection) для запросов без Hostс error_page 400...вид работ, но будет держать соединение открытым. NGINX пытается сделать внутреннее перенаправление на ресурс 444? Не хороший.
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95154507_54154259
@Gerben так триггер для 444 должен быть всегда 400?
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95155943_54154259
Все 444. Т. е. нет ответа на любые запросы без заголовка Host. Включая искаженные запросы (400)
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95158315_54154259
@Gerben правильный 444 возвращается только модулем деградации . Вы должны были скомпилировать свою собственную версию, вероятно, или, по крайней мере, реализовать собственный модуль.
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95171544_54154259
№ Только стандартная установка debian nginx (1.10.3 на Jessie)
https://stackoverflow.com/questions/40480528/how-to-set-nginx-uri-to-fix-empty-uri-in-redirect-to-named-location/54154259#comment95181347_54154259
@Gerben Вероятно, вы не получите желаемое закрытое соединение всегда
Jean Monet

20.11.2019 08:44:53

У меня была та же цель (возвращение 444, а не индивидуальные сообщения об ошибках) и столкнулся с той же проблемой с помощью @named_location (для некоторых странных запросов, в частности, когда нет поста/Вам/глава метода, указанного в заголовке, nginx возвращал его по умолчанию 500 ошибка страницы и ошибки в журнале сообщала: empty URI in redirect to named location "@named_location" while reading client request).

Кто-то открыл билет с Nginx, вот ответ:

[...] проблема заключается в том, что вы пытаетесь перенаправить ошибки, которые появляются на ранних этапах обработки запроса - когда URI запроса еще не проанализирован - в именованное местоположение. Именованные расположения предназначены для сохранения существующего URI запроса, и перенаправление такого неполного запроса в именованное расположение может вызвать серьезные проблемы в других частях кода. Таким образом, попытка сделать такое перенаправление приводит к ошибке "пустой URI в перенаправлении на именованное местоположение". Это, в свою очередь, предотвращает использование пользовательской страницы ошибок, поэтому возвращается внутренняя страница. Если вы хотите обрабатывать ошибки, которые появляются на ранних этапах обработки запроса, например 400 неверных запросов, рассмотрите возможность использования страниц ошибок с явно заданным URI. Или вы можете вместо этого избегать попыток перенаправления таких ошибок, так как это, как правило, гораздо более безопасный подход. Обратите внимание, что тот факт, что сервер nginx не является утечкой информации. Это в любом случае сообщается несколькими способами, включая заголовок ответа сервера. Если вы по какой-то причине хотите скрыть версию nginx, вы можете сделать это с помощью директивы server_tokens.

Поэтому я изменил настройку ошибок следующим образом:

error_page 301 400 403 404 500 502 503 504 =444 /444.html;
location = /444.html {
        return 444;
}

# Instead of:
# error_page 301 400 403 404 500 502 503 504 =444 @named_location;
# location @named_locations {
#         return 444;
# }
# which gives the above-mentioned error and returns Nginx's default 500 error page.

Это, кажется, решило проблему.

Закрыть X