444 ошибка http

Время прочтения
7 мин

Просмотры 31K

В web-сервере Nginx есть замечательный код ответа 444, который «закрывает» соединение без отправки данных. Данный функционал весьма полезен при фильтрации паразитного трафика — если мы уверены, что клиент по каким-то критериям не является валидным, то нет необходимости его уведомлять, например, 403-м ответом. Эффективнее просто прекратить передачу данных, что, зачастую, позволяет существенно снизить нагрузку на сервер.

Рекомендации использовать такие ответы можно встретить повсеместно в инструкциях по блокировках переходов по ссылкам с популярных сайтов и реферального спама, защите от DDoS и т.п.

И, в общем-то, на протяжении многих лет эти советы можно было использовать почти не глядя, но… современные браузеры не стоят на месте и периодически преподносят нам новые сюрпризы.

$ uname -orm
FreeBSD 11.1-STABLE amd64

$ nginx -v
nginx version: nginx/1.15.0

>ver
Microsoft Windows [Version 10.0.15063]

Я взял для опытов только браузеры Chrome и Firefox. Не потому, что остальные безгрешны, просто в этих двух описанное ниже поведение было достаточно стабильным.

Итак, у нас есть сайт и мы хотим ограничить доступ к location без всяких условий и не передавая никаких данных:

server {
...
  location = /code/444 {
    return 444;
  }
...
}

Ожидание:

• браузер отправит один запрос;
• сервер получит один запрос, закроет соединение и запишет в лог одну строку с кодом 444;
• не получив данных браузер отобразит ошибку и прекратит общение с сервером.

Для большей наглядности отобразим наше ожидание строкой лога Nginx:

18.12.12.29 - - [28/Jun/2018:11:50:10 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"

Реальность Chrome:

18.12.12.29 - - [28/Jun/2018:11:50:10 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
18.12.12.29 - - [28/Jun/2018:11:50:10 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
18.12.12.29 - - [28/Jun/2018:11:50:15 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
18.12.12.29 - - [28/Jun/2018:11:52:04 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"

Chrome отправил запрос, не получил ответа, тут же отправил ещё один запрос, после чего стал периодически проверять сайт на доступность.

Реальность Firefox:

18.12.12.29 - - [28/Jun/2018:12:34:38 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:38 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:38 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:38 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:38 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:39 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:40 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:40 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:40 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:40 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:40 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:41 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:41 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:41 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:34:41 +0000] "GET /code/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"

Firefox решил не мелочиться и сразу же отправил 20 запросов (иногда делает 10). Но потом уже не совершает «проверок».

При этом в отладчике он отчитывается как за один запрос:

Тем самым, ожидая получить один запрос от клиента, на деле мы получаем 3-20 запросов. Кроме совсем ненужных нам обращений есть риск скормить такой лог, например, анти-DDoS скрипту и заблокировать данный ip. И казалось бы полбеды, ведь мы и так ему «отдавали» 444, то есть нам его не жалко, но может случиться и наоборот — мы покажем клиенту то чего не вообще планировали.

Модифицируем конфиг:

map $http_referer     $code_if {
    "~*https://habr.com/post/415565/" 1;
    "http://tison.ru/ref" 1;
    default 0;
}
...
server {
...
  location = /code/444 {
    return 444;
  }
...
  location = /codeif/444 {
    if ( $code_if = 1 ) { return 444; }
    add_header "Content-Type" "text/html; charset=UTF-8" always;
    return 200 "Expected code 444";
}
...
}

Здесь мы запретили отдачу контента всем клиентам имеющим реферер «
https://habr.com/post/415565/» при переходе на страничку tison.ru/codeif/444

Ожидание:

Зная уже описанные выше особенности, мы допустим, что браузеры сделают более одного запроса, но 200-го ответа от сервера они не получат.

В виде лога, опять же, ожидаем одну или несколько строк вида:

18.12.12.29 - - [28/Jun/2018:12:52:02 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"

При отладке в консоли всё работает ожидаемо. Сервер закрыл соединение и никакого контента мы не получили:

$ curl --referer "https://habr.com/post/415565/" tison.ru/codeif/444
curl: (52) Empty reply from server

Ну и браузерная реальность.

Chrome:

18.12.12.29 - - [28/Jun/2018:12:58:12 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
18.12.12.29 - - [28/Jun/2018:12:58:12 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
18.12.12.29 - - [28/Jun/2018:12:58:13 +0000] "GET /codeif/444 HTTP/1.1" 200 17 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"

Firefox:

18.12.12.29 - - [28/Jun/2018:12:56:29 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:29 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:29 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:29 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:30 +0000] "GET /codeif/444 HTTP/1.1" 444 0 "http://tison.ru/ref" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:31 +0000] "GET /codeif/444 HTTP/1.1" 200 17 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
18.12.12.29 - - [28/Jun/2018:12:56:31 +0000] "GET /favicon.ico HTTP/1.1" 200 6782 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"

Сделав несколько «честных» запросов запросов оба браузера отбросили реферер и спокойно отобразили блокируемую страницу. Firefox, правда, делает это не всегда. На моих тестах ~ в 15% запросов, что ещё больше «помогает» в анализе.

Такое поведение наблюдается уже достаточно давно, но когда именно Chrome и Firefox перешли на данный режим работы сказать не могу. Как впрочем и сколько времени этот режим будет действовать.

Поэтому сегодня использование return 444 не всегда приведёт к ожидаемым результатам. Ну а завтра, с нетерпением будем ждать, чем нас ещё порадуют разработчики браузеров.

Как исправить время выполнения Ошибка 444 Метод неприменим в данном контексте

В этой статье представлена ошибка с номером Ошибка 444, известная как Метод неприменим в данном контексте, описанная как Вы не можете использовать этот метод в текущей процедуре обработки события.

Информация об ошибке

Имя ошибки: Метод неприменим в данном контексте
Номер ошибки: Ошибка 444
Описание: Вы не можете использовать этот метод в текущей процедуре обработки события.
Программное обеспечение: Windows
Разработчик: Microsoft

Этот инструмент исправления может устранить такие распространенные компьютерные ошибки, как BSODs, зависание системы и сбои. Он может заменить отсутствующие файлы операционной системы и библиотеки DLL, удалить вредоносное ПО и устранить вызванные им повреждения, а также оптимизировать ваш компьютер для максимальной производительности.

О программе Runtime Ошибка 444

Время выполнения Ошибка 444 происходит, когда Windows дает сбой или падает во время запуска, отсюда и название. Это не обязательно означает, что код был каким-то образом поврежден, просто он не сработал во время выполнения. Такая ошибка появляется на экране в виде раздражающего уведомления, если ее не устранить. Вот симптомы, причины и способы устранения проблемы.

Определения (Бета)

Здесь мы приводим некоторые определения слов, содержащихся в вашей ошибке, в попытке помочь вам понять вашу проблему. Эта работа продолжается, поэтому иногда мы можем неправильно определить слово, так что не стесняйтесь пропустить этот раздел!

• Контекст — go-context
• Процедура — процедура — это подпрограмма, которая не возвращает значение Метод . Метод, который часто называют функцией, подпрограммой или процедурой, представляет собой код, который выполняет задачу и связан с классом или объектом.
• Событие — Событие — это способ для класса предоставлять слушателям уведомления, когда происходит определенное событие.

Симптомы Ошибка 444 — Метод неприменим в данном контексте

Ошибки времени выполнения происходят без предупреждения. Сообщение об ошибке может появиться на экране при любом запуске %программы%. Фактически, сообщение об ошибке или другое диалоговое окно может появляться снова и снова, если не принять меры на ранней стадии.

Возможны случаи удаления файлов или появления новых файлов. Хотя этот симптом в основном связан с заражением вирусом, его можно отнести к симптомам ошибки времени выполнения, поскольку заражение вирусом является одной из причин ошибки времени выполнения. Пользователь также может столкнуться с внезапным падением скорости интернет-соединения, но, опять же, это не всегда так.

(Метод неприменим в данном контексте) Repair Tool»/>
(Только для примера)

Причины Метод неприменим в данном контексте — Ошибка 444

При разработке программного обеспечения программисты составляют код, предвидя возникновение ошибок. Однако идеальных проектов не бывает, поскольку ошибки можно ожидать даже при самом лучшем дизайне программы. Глюки могут произойти во время выполнения программы, если определенная ошибка не была обнаружена и устранена во время проектирования и тестирования.

Ошибки во время выполнения обычно вызваны несовместимостью программ, запущенных в одно и то же время. Они также могут возникать из-за проблем с памятью, плохого графического драйвера или заражения вирусом. Каким бы ни был случай, проблему необходимо решить немедленно, чтобы избежать дальнейших проблем. Ниже приведены способы устранения ошибки.

Методы исправления

Ошибки времени выполнения могут быть раздражающими и постоянными, но это не совсем безнадежно, существует возможность ремонта. Вот способы сделать это.

Если метод ремонта вам подошел, пожалуйста, нажмите кнопку upvote слева от ответа, это позволит другим пользователям узнать, какой метод ремонта на данный момент работает лучше всего.

Источник

Почему (сегодня) return 444 не всегда полезен

В web-сервере Nginx есть замечательный код ответа 444, который «закрывает» соединение без отправки данных. Данный функционал весьма полезен при фильтрации паразитного трафика — если мы уверены, что клиент по каким-то критериям не является валидным, то нет необходимости его уведомлять, например, 403-м ответом. Эффективнее просто прекратить передачу данных, что, зачастую, позволяет существенно снизить нагрузку на сервер.

Рекомендации использовать такие ответы можно встретить повсеместно в инструкциях по блокировках переходов по ссылкам с популярных сайтов и реферального спама, защите от DDoS и т.п.

И, в общем-то, на протяжении многих лет эти советы можно было использовать почти не глядя, но… современные браузеры не стоят на месте и периодически преподносят нам новые сюрпризы.

Google Chrome 67.0.3396.99 (Официальная сборка), (64 бит)
Firefox Quantum 61.0 (64-бит)

Я взял для опытов только браузеры Chrome и Firefox. Не потому, что остальные безгрешны, просто в этих двух описанное ниже поведение было достаточно стабильным.

Итак, у нас есть сайт и мы хотим ограничить доступ к location без всяких условий и не передавая никаких данных:

• браузер отправит один запрос;
• сервер получит один запрос, закроет соединение и запишет в лог одну строку с кодом 444;
• не получив данных браузер отобразит ошибку и прекратит общение с сервером.

Для большей наглядности отобразим наше ожидание строкой лога Nginx:

Chrome отправил запрос, не получил ответа, тут же отправил ещё один запрос, после чего стал периодически проверять сайт на доступность.

Firefox решил не мелочиться и сразу же отправил 20 запросов (иногда делает 10). Но потом уже не совершает «проверок».

При этом в отладчике он отчитывается как за один запрос:

Тем самым, ожидая получить один запрос от клиента, на деле мы получаем 3-20 запросов. Кроме совсем ненужных нам обращений есть риск скормить такой лог, например, анти-DDoS скрипту и заблокировать данный ip. И казалось бы полбеды, ведь мы и так ему «отдавали» 444, то есть нам его не жалко, но может случиться и наоборот — мы покажем клиенту то чего не вообще планировали.

Здесь мы запретили отдачу контента всем клиентам имеющим реферер »
https://habr.com/post/415565/ » при переходе на страничку tison.ru/codeif/444

Зная уже описанные выше особенности, мы допустим, что браузеры сделают более одного запроса, но 200-го ответа от сервера они не получат.

В виде лога, опять же, ожидаем одну или несколько строк вида:

При отладке в консоли всё работает ожидаемо. Сервер закрыл соединение и никакого контента мы не получили:

Ну и браузерная реальность.

Сделав несколько «честных» запросов запросов оба браузера отбросили реферер и спокойно отобразили блокируемую страницу. Firefox, правда, делает это не всегда. На моих тестах

в 15% запросов, что ещё больше «помогает» в анализе.

Такое поведение наблюдается уже достаточно давно, но когда именно Chrome и Firefox перешли на данный режим работы сказать не могу. Как впрочем и сколько времени этот режим будет действовать.

Поэтому сегодня использование return 444 не всегда приведёт к ожидаемым результатам. Ну а завтра, с нетерпением будем ждать, чем нас ещё порадуют разработчики браузеров.

Источник

Коды ответов и ошибок сервера 100 . 403, 404 . 511

Удобный справочник кодов состояния соединения.

Код состояния HTTP — это часть первой строки ответа сервера при запросах по протоколу.

Содержание.

100.

Информационные

100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки.

101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.

105 Name Not Resolved — возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

Успешные

200 OK — успешный запрос. Клиенту отправлены запрошенные данные.

201 Created — в результате успешного выполнения запроса был создан новый ресурс. Если ресурс не может быть создан в данный момент, то сервер вместо этого должен отобразить код 202.

202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как процесс может занять много времени.

203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника, а из резервной копии, с другого сервера и т.д… Поэтому инфа может быть неактуальной.

204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

Используется для того, чтобы позволить осуществить ввод или какие-либо действия без необходимости обновлять документ (страницу).

205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные, при этом тело сообщения не передаётся, поэтому страницу обновлять не обязательно.

Используется когда пользователь заполняет форму, а сервер посылает браузеру запрос на очистку формы.

206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого.

207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus.

226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Перенаправление

300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список вариантов, давая клиенту сделать выбор.

Такое происходит, когда пользователь использует URL на директорию не самого последнего уровня, и сервер предлагает ему выбор имеющихся файлов или директорий последующего уровня.

301 Moved Permanently — запрошенный документ был перенесен на новый URI адрес которого указанный в поле Location.
Некоторые клиенты некорректно ведут себя при обработке данного кода.

302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location.
Изначально представлял собой основной способ создания временного перенаправления. Тем не менее, сегодня существуют и другие – этичные, и неэтичные – способы его применения.

303 See Other — код указывает пользователю на то, что запрашиваемый ресурс можно найти по URL, который отличается от указанного в запросе. Это не обязательно означает, что что-то было перемещено, этот код лишь предоставляет адрес, по которому следует запрашивать подобный ответ.
Этот метод главным образом существует для того, чтобы позволить выводу данных POST-активированного скрипта перенаправить агента пользователя к выбранному ресурсу.

304 Not Modified — сервер возвращает такой код, если документ не изменился с момента последнего посещения сервера клиентом.
В этом коде сообщается о том, что параметры документа If-Modified-Since или If-Match не менялись с момента создания последнего кэша, и нет необходимости в повторной отправке ресурса.

305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси).

306 — использовался раньше, в настоящий момент зарезервирован.

307 Temporary Redirect — запрашиваемый ресурс, на короткое время, доступен по другому URI указанному в поле Location. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности.

Ошибки клиента

400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку.

401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация.
Ответ сервера должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в сообщение требуемые для аутентификации данные.

402 Payment Required — предполагается использовать в будущем, сейчас не используется.
Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг.

403 Forbidden — сервер понял запрос, но отказался его выполнять из-за ограничений в доступе к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения.
Наиболее вероятными причинами ограничения, может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или сервер не удовлетворён IP-адресом клиента, например, при блокировках.

404 Not Found — самая распространенная ошибка в интернете, основная причина — ошибка в написании адреса Web-страницы.
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.

405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу.
В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented).

406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT.

409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone — сервер посылает такой код если ресурс раньше был по указанному URL, но был удалён и теперь недоступен.
Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411 Length Required — сервер сообщает, что клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём.

412 Precondition Failed — возвращается, если ни одно из полей запроса не было выполнено.
Иными словами, один или более заголовок запроса был возвращен с атрибутом false.

413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса.
Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type — сервер заметил, что часть запроса была сделана в неподдерживаемом формате.
В запросе не указываются какие-либо типы медиа, которые поддерживаются ресурсом или сервером. Например, пользователь запрашивает изображение с расширением файла, которое не поддерживается сервером.

416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка.

417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса

418 I’m a teapot — код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol.
Не ожидается, что данный код будет поддерживаться реальными серверами.

422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом.

423 Locked — целевой ресурс заблокирован от применения к нему указанного метода.

424 Failed Dependency — указывает на то, что реализация текущего запроса может зависеть от успешности выполнения другой операции, и если она не будет успешно проведена, то вся обработка запроса будет прервана.

425 Unordered Collection — используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.

426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

428 Precondition Required — сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.

429 Too Many Requests — клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.

431 Request Header Fields Too Large — превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.

434 Requested host unavailable — запрашиваемый адрес недоступен.

444 — возвращается только сервером nginx. Бывают случаи, когда вы можете распознать по неким признакам бота, сканер или хакера. В таких случаях хорошо бы просто закрывать соединение. Вот для таких случаев и создан ответ 444. Собственно NGINX просто посылает в ответ пустой пакет (без заголовков) TCP RST и закрывает соединение.

449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».

456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 — используется Nginx, когда клиент закрывает соединение до получения ответа.

Ошибка сервера

500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса.

501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.

502 Bad Gateway — сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера.

503 Service Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается.

507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510 Not Extended — на сервере отсутствует расширение, которое запрашивает клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником, например сервером провайдера — если клиент должен сначала авторизоваться в сети. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

Источник

Short version:

I want to use NGINX as a reverse proxy so that a client accessing the public facing URL gets served API data from the internal Gunicorn server sitting behind the proxy:

external path (proxy) => internal app
<static IP>/ABC/data  => 127.0.0.1:8001/data

I’m not getting the location mapping correct.

Long version:

I am setting up NGINX for the first time and am attempting to use it as a reverse proxy for a rest api served by Gunicorn. The api is served at 127.0.0.1:8001 and I can access it from the server and get the appropriate responses, so that piece I believe is working correctly. It’s running persistently using Supervisord.

I’d like to access one of the API endpoints externally at <static IP>/ABC/data. On the Gunicorn server, this endpoint available at localhost:8001/data. Eventually I’d like to serve other web apps through NGINX with roots like <static IP>/foo, <static IP>/bar, etc. Each of these web apps would be from an independent Python app. But currently, when I try to access the endpoint externally, I get a 444 error code, so I think I am not configuring NGINX correctly.

I put together my first attempt at an NGINX config from the config posted on the Guincorn site. Instead of a single config, I’ve split it into a global config and a site specific one. My global config at etc/nginx/nginx.conf looks like:

user ops;
worker_processes 1;
pid /run/nginx.pid;
error_log /tmp/nginx.error.log;

events {
  worker_connections 1024; # increase if you have lots of clients
  accept_mutex off; # set to 'on' if nginx worker_processes > 1
  use epoll;
  # 'use epoll;' to enable for Linux 2.6+
  # 'use kqueue;' to enable for FreeBSD, OSX
}

http {
  include mime.types;
  # fallback in case we can't determine a type
  default_type application/octet-stream;
  access_log /tmp/nginx.access.log combined;
  sendfile on;

  server_tokens off;

  server {
    # if no Host match, close the connection to prevent host spoofing
    listen 80 default_server;
    return 444;
  }

  gzip on;
  gzip_disable "msie6";

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

Then my site specific configuration that is in /etc/nginx/sites-available (and is symlinked in /etc/nginx/sites-enabled) is:

upstream app_server {
  # fail_timeout=0 means we always retry an upstream even if it failed
  # to return a good HTTP response

  # for UNIX domain socket setups
  # server unix:/tmp/gunicorn_abc_api.sock fail_timeout=0;

  # for a TCP configuration
  server 127.0.0.1:8001 fail_timeout=0;
}

server {
  # use 'listen 80 deferred;' for Linux
  # use 'listen 80 accept_filter=httpready;' for FreeBSD
  listen 80 deferred;
  client_max_body_size 4G;

  # set the correct host(s) for your site
  server_name _;

  keepalive_timeout 100;

  # path for static files
  #root /path/to/app/current/public;

  location /ABC {
    # checks for static file, if not found proxy to app
    try_files $uri @proxy_to_app;
  }

  location @proxy_to_app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # enable this if and only if you use HTTPS
    # proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;
    # we don't want nginx trying to do something clever with
    # redirects, we set the Host: header above already.
    proxy_redirect off;
    proxy_pass http://app_server;
  }

  # error_page 500 502 503 504 /500.html;
  # location = /500.html {
  #   root /path/to/app/current/public;
  # }
}

The configs pass service nginx checkconfig, but I end up seeing the following in my access log:

XXX.XXX.X.XXX - - [09/Sep/2016:01:03:18 +0000] "GET /ABC/data HTTP/1.1" 444 0 "-" "python-requests/2.10.0"

I think I’ve somehow not configured the routes properly. Any suggestions would be appreciated.

UPDATE:

I have it working now with a few changes. I commented out the following block:

  server {
    # if no Host match, close the connection to prevent host spoofing
    listen 80 default_server;
    return 444;
  }

I can’t figure out how to get the behavior of returning 444 unless there is a valid route. I’d like to, but I’m still stuck on this part. This block seems to eat all incoming requests. I’ve also changed the app config to:

upstream app_server {
    server 127.0.0.1:8001 fail_timeout=0;
}

server {
    # use 'listen 80 deferred;' for Linux
    # use 'listen 80 accept_filter=httpready;' for FreeBSD
    listen 80 deferred;
    client_max_body_size 100M;

    # set the correct host(s) for your site
    server_name $hostname;

    keepalive_timeout 100;

    location /ABC {
    # checks for static file, if not found proxy to app
    try_files $uri @proxy_to_app;
    }

    location @proxy_to_app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # enable this if and only if you use HTTPS
    # proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;
    # we don't want nginx trying to do something clever with
    # redirects, we set the Host: header above already.
    proxy_redirect off;
    rewrite ^/ABC/(.*) /$1 break;
    proxy_pass http://app_server;
    }

}

Basically I seem to have had to explicity set server_name and also use rewrite to get the correct mapping to the app server.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.