Коды состояний HTTP
Данная страница основана на информации о кодах состояний HTTP. Оригинальными источниками являются ietf.org и Wikipedia. Кликните по заголовку категории или коду состояния для получения подробной информации.
1xx: Information
В этот класс выделены коды, информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков для этого класса кодов состояния. Из-за того, что стандарт протокола HTTP/1.0 не определял никаких 1xx кодов состояния, серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам, за исключением экспериментальных условий.
Клиент должен быть готов принять один или несколько 1xx ответов статуса до завершения передачи, даже если клиент не ожидает статуса 100 (Продолжить). Неожиданные 1xx ответы могут быть проигнорированы агентом пользователя.
Прокси должен направить 1xx ответы, если соединение между прокси-сервером и клиентом было закрыто, или если прокси-сервер сам просил 1xx ответ. (Например, если прокси-сервер добавляет "Expect: 100-continue" поле, когда он перенаправляет запрос, то нужно отправить соответствующий 100 (Continue) код ответа).
Wikipedia
В этот класс выделены коды, информирующие о процессе передачи. При работе через протокол HTTP версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
Клиент должен продолжать свой Запрос. Этот промежуточный ответ используется для сообщения клиенту о том, что начальная часть запроса была получена и ещё не была отвергнута сервером. Клиенту СЛЕДУЕТ продолжить посылку оставшихся данных запроса или, если запрос уже был выполнен, игнорировать этот ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен. См. раздел 8.2.3 для детального обсуждения использования и обработки этого кода состояния.
Wikipedia
Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
Сервер понимает и готов выполнить запрос клиента через поле заголовка сообщения Upgrade (раздел 14.42) об изменении протокола приложения, используемого в этом соединении. Сервер переключит протоколы на те, которые определены в поле заголовка Upgrade ответа сразу после пустой строки, завершающей ответ 101.
Протокол СЛЕДУЕТ переключать только тогда, когда это выгодно. Например, переключение на более новую версию HTTP выгодно по сравнению со старыми версиями, а переключение на синхронный протокол реального времени может быть выгодным при доставке ресурсов, которые используют такие функции.
Wikipedia
Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Upgrade. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
Этот промежуточный ответ используется для информирования клиента о том, что сервер принял на себя полный запрос, но ещё не завершил его. Этот статус код должен быть послан только когда сервер имеет разумные основания ожидать, что запрос займёт значительное время. В качестве ориентира, если метод занимает больше времени, чем на 20 секунд (разумное, но произвольное значение) для обработки сервер должен вернуть 102 (Processing) ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен.
Методы потенциально могут занять длительный период времени для процесса, особенно если они поддерживают заголовок Depth. В таких случаях клиент может прервать соединение по тайм-ауту во время ожидания ответа. Чтобы предотвратить это, сервер может вернуть 102 (Processing) код состояния, указывая клиенту, что сервер всё ещё обрабатывается методом.
Wikipedia
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.
2xx: Success
Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят и принят.
Wikipedia
Этот класс кодов состояния указывает, что действие, запрошенное клиентом, было получено, понято и принято.
Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например:
- GET Получить объект, соответствующий запрошенному ресурсу в ответ;
- HEAD Поля заголовков, соответствующие запрошенному ресурсу отправляются в ответ без какого-либо тела сообщения;
- POST Созданный объект или иной результат действия;
- TRACE Объект, содержащий сообщение запроса, полученное сервером.
Wikipedia
Стандартный ответ для запросов по HTTP.
Основной код ответа. Обычно используется для того, чтобы показать успешность выполненной операции.
Запрос был выполнен, и в результате был создан новый ресурс. На вновь созданный ресурс можно ссылаться с помощью URI, возвращаемого в сущности ответа, с наиболее конкретным URI для ресурса, заданным полем заголовка Location. В ответ СЛЕДУЕТ включать объект, содержащий список характеристик ресурса и местоположения, из которых пользователь или пользовательский агент может выбрать наиболее подходящий. Формат объекта определяется типом носителя, указанным в поле заголовка Content-Type. Исходный сервер ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер ДОЛЖЕН ответить ответом 202 (Принято).
Ответ 201 МОЖЕТ содержать поле заголовка ответа ETag, указывающее текущее значение тега объекта для только что созданного запрошенного варианта, см. Раздел 14.19.
Wikipedia
Запрос был выполнен и в результате был создан новый ресурс.
Подтверждение успешного создания (например посредством POST или PUT запроса). Заголовок Location содержит ссылку на только что созданный ресурс (при POST запросе). Тело ответа может быть пустым. Обычно так и бывает.
Запрос принят в обработку, но ещё не завершен. Нет никаких гарантий, что запрос успешно выполнится в процессе обработки данных. Из-за асинхронного типа выполняемой операции отсутствует возможность повторной отправки статуса.
Данный ответ ничему не обязывает. Основной целью этого запроса является уведомить клиента о том, что запрос принят в обработку и, ввиду того, что наличие соединения между клиентом и сервером после этого не обязательно, позволить серверу принять запрос от другого клиента/для другого процесса. В ответе должно также возвращаться состояние выполнение запроса или ссылка на источник, где пользователь может проверить статус выполнения задачи или убедиться в её завершении.
Wikipedia
Запрос был принят на обработку, но она не завершена. Клиенту необязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
Предоставленная информация взята не из оригинального источника (а, например, из кэша, который мог устареть, или из резервной копии, которая могла потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предоставленная информация может совпадать, а может и не совпадать с оригинальными данными.
Wikipedia
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.
Появился в HTTP/1.1.
Запрос был успешно обработан, но нет необходимости возвращать какие-либо данные. Так же в ответе может возвращаться новая, или обновлённая информация, однако в итоге она не будет отличаться о того, что было изначально послано на сервер и, таким образом, считается что клиент и так обладает актуальной информацией.
Если клиентом является браузер — то он не должен изменять отображение документа, и его состояние до момента отправки запроса и после этого — не должно изменяться. Этот статус ответа в основном применяется для индикации успешности выполнения запроса с учётом того, что данные и их представление не должны изменится, не смотря (или с учётом того), что новая (обновлённая информация) уже отображена в представлении документа.
Ответ 204 НЕ ДОЛЖЕН включать тело сообщения. Если таковое имеется — оно обычно игнорируется и считается что после заголовков присутствует одна пустая линия.
Wikipedia
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
Статус используется, когда ответ не используется или когда нет контента (например при выполнении команды DELETE)
Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяется для возврата в начальное состояние формы ввода данных на клиенте.
Wikipedia
Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт, и документ обновлять необязательно. Появился в HTTP/1.1.
Сервер выполнил часть GET запроса ресурса. Запрос ДОЛЖЕН был содержать поле заголовка Range (секция 14.35), который указывает на желаемый диапазон и МОГ содержать поле заголовка If-Range (секция 14.27), который делает запрос условным.
Запрос ДОЛЖЕН содержать следующие поля заголовка:
- Либо поле Content-Range (секция 14.16), который показывает диапазон, включённый в этот запрос, либо Content-Type со значением multipart/byteranges, включающими в себя поля Content-Range для каждой части. Если в заголовке запроса есть поле Content-Length, его значение ДОЛЖНО совпадать с фактическим количеством октетов, переданных в теле сообщения.
- Date
- ETag и/или Content-Location, если ранее был получен ответ 200 на такой же запрос.
- Expires, Cache-Control, и/или Vary, если значение поля изменилось с момента отправления последнего такого же запроса
Если ответ 206 - это результат выполнения условного запроса, который использовал строгий кэш-валидатор (подробнее в секции 13.3.3), в ответ НЕ СЛЕДУЕТ включать какие-либо другие заголовки сущности. Если такой ответ — результат выполнения запроса If-Range, который использовал "слабый" валидатор, то ответ НЕ ДОЛЖЕН содержать другие заголовки сущности; это предотвращает несоответствие между закэшированными телами сущностей и обновлёнными заголовками. В противном случае ответ ДОЛЖЕН содержать все заголовки сущностей, которые вернули статус 200 (OK) на тот же запрос.
Кэш НЕ ДОЛЖЕН объединять ответ 206 с другими ранее закэшированными данными, если поле ETag или Last-Modified в точности не совпадают (подробнее в секции 16.5.4)
Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы 206 (Partial).
Wikipedia
Сервер передает только ту часть ресурса, которая была указана клиентом в заголовке диапазона. Заголовок диапазона используется такими инструментами, как wget, для возобновления прерванных загрузок или для разделения загрузки на несколько параллельных потоков.
Код 207 (Multi-Status) позволяет передавать статусы для нескольких независимых операций (за подробностями в секцию 11).
Wikipedia
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
Относится к DAV и был ранее включён в 207 ответ. Там поныне и остаётся.
Wikipedia
На сайте описание отсутствует
Сервер успешно принял запрос для ресурса и ответ является представлением результата применения одной или нескольких манипуляций с экземпляром ресурса. На самом деле актуальное представление ресурса может быть в текущий момент не доступно ввиду того, что действие может быть глобальное и затрагивать несколько экземпляров ресурса, а соответственно может комбинироваться с предыдущим или возможным в будущем ответом, связанным со специфичными действиями над конкретным экземпляром ресурса (или ресурсов). Если это так, то при формировании заголовков для конкретного экземпляра (или в результирующих заголовках, отталкивающихся от 226 ответа и других экземпляров) нужно руководствоваться частью 13.5.3 спецификации HTTP/1.1.
Запрос обязан содержать в A-IM заголовке перечень как минимум одной манипуляции с экземпляром. Ответ обязан содержать ETag заголовок с тегом для конкретного экземпляра.
Ответ переданный с 226 кодом может быть закэширован и использован в ответах, актуальность которых регулируется Cache-Control заголовком, а также требованиями, которые описаны в секции 10.6.
Ответ, переданный с кодом 226 может быть использован в совокупности с имеющимися закэшированными сущностями для базового экземпляра для создания кэшированной сущности для конкретного экземпляра.
Wikipedia
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
3xx: Redirect
Данный класс кодов состояния показывает, что дальнейшие действия должны быть выполнены клиентом для того, чтобы запрос завершился успешно. Требуемое действие может быть выполнено клиентом без участия пользователя тогда и только тогда, когда следующий запрос будет GET или HEAD. Клиент обязан обнаруживать бесконечные циклы перенаправлений, потому что они генерируют бессмысленный трафик.
Замечание: предыдущая версия спецификации допускала максимум 5 перенаправлений. Разработчики должны иметь это ввиду.
Wikipedia
Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.
По последним стандартам клиент может производить перенаправление без запроса пользователя только, если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход.
Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только, если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.
Запрошенный ресурс имеет множество представлений, каждое из которых имеет своё расположение, и предоставляется управляемая агентом информация о переговорах (раздел 12), чтобы пользователь (или пользовательский агент) мог выбрать предпочтительное представление и перенаправить его запрос в это место.
Если это не запрос HEAD, ответ ДОЛЖЕН включать объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведённых в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако эта спецификация не определяет никакого стандарта для автоматического выбора.
Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; агент пользователя МОЖЕТ использовать заголовок Location для автоматического перенаправления к предложенному ресурсу. Этот запрос может быть закэширован, если явно не было указано иного.
Wikipedia
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
Запрашиваемому ресурсу был установлен новый URI и будущие обращения к этому ресурсу должны осуществляться по возвращённому URI. Клиенты с возможностью редактирования должны автоматически переопределить ссылки на Request-URI для одной или более новых ссылок, возвращённых сервером, где это возможно. Этот ответ является кэшируемым если не указано иное.
Новый постоянный URI должен быть передан в Location заголовке в ответе. Если запрос был не HEAD - в ответе должно содержаться краткое описание того, что адрес изменился со ссылкой на новый адрес. Данная информация должна быть предоставлена в виде HTML.
Если 301 статус получен в ответ на запрос, отличный от GET или HEAD, агент пользователя не обязан автоматически перенаправлять в случае, если пользователь не может подтвердить это действие.
Замечание: Некоторые HTTP/1.0 клиенты, после автоматического перенаправления POST запроса, после принятия 301 статуса, ошибочно преобразуют его в GET запрос.
Wikipedia
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
Запрошенный ресурс временно находится под другим URI. Так как перенаправление может быть изменено в любой момент, клиенту СЛЕДУЕТ продолжать использовать тот же самый URI для будущих запросов. Этот ответ является кэшируемым если не было назначено Cache-Control или Expires поля заголовка.
Временный URI должен быть передан в Location заголовке в ответ на запрос. В случае, если запрос был не HEAD - в ответе должно содержаться упоминание о новом URI в гипертекстовом представлении.
Если 302 статус передан в ответе на отличный от GET или HEAD запрос, клиент не должен автоматически выполнять перенаправление, если это действие не может быть подтверждено пользователем, так как это может изменить условия, которые подразумевал исходный запрос.
Замечание: RFC 1945 и RFC 2068 описывают, что клиенту недопустимо изменять метод исходного запроса при перенаправлении. Тем не менее большинство существующих реализаций User Agent обрабатывает 302 как будто был передан ответ 303, выполняя GET для адреса, переданного в Location, независимо от исходного метода запроса. Статусы 303 и 307 были добавлены для серверов, которым необходимо однозначно понимать, какой вид реакции ожидать от клиента.
Wikipedia
Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
Документ по запрошенному адресу может быть найден по другому URI и должен быть найден с использованием GET запроса. Этот метод существует прежде всего, чтобы позволить выход из POST-активированной сценария, используя перенаправление агента пользователя на указанный ресурс. Новый URI не является заменой для исходного адреса. 303 статус не должен быть закэширован, однако ресурс, куда будет выполнено перенаправления — может быть закэширован.
Новый URI должен быть передан посредством Location в ответе. В случае, если исходный запрос был отличен от HEAD - в ответе должна содержаться ссылка на новый URI в гипертекстовом формате.
Замечание: Многие агенты, до HTTP/1.1 не понимают статуса 303. Когда взаимодействие с такими клиентами является проблемой, код состояния 302 может быть использован вместо 303, так как большинство агентов реагируют на ответ 302, так же как на 303.
Wikipedia
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска.
Введено в HTTP/1.1
Если клиент выполнил условный запрос GET и доступ разрешен, но документ не был изменен, сервер должен ответить, используя этот код состояния. Ответ 304 НЕ ДОЛЖЕН содержать тела сообщения, и, таким образом, всегда завершается первой пустой строкой после полей заголовка.
Ответ должен содержать следующие заголовки:
- Дата, если её отсутствия не требует раздел 14.18.1
Если сервер подчиняется этим правилам, и прокси-серверы и клиенты добавят свои собственные Даты к любому ответу, полученному без Даты (как уже указано [RFC 2068], раздел 14.19), кэши будут работать правильно.
- ETag и/или Content-Location, если заголовки передаются с 200 кодом ответа.
- Expires, Cache-Control, и/или Vary, если значения полей изменились с последнего ответа на предыдущие аналогичные запросы.
Если условный GET запрос использует строгую валидацию на присутствие в кэше (см 13.3.3) ответ НЕ должен (желательно) включать другие заголовки. В противном случае ответ НЕ должен (обязательно) включать другие заголовки. Это предотвращает нарушение согласованности данных в кэше и модификации заголовков.
Если при 304 ответе наблюдается отсутствие сущности в актуальном кэше, запрос должен быть продолжен без проверки присутствия кэша.
Если кэш использует полученный 304 ответ для обновления кэша, кэш ДОЛЖЕН обновить запись, чтобы отразить любые новые значения полей, переданных в ответ.
Wikipedia
Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
Используется для условных GET запросов для снижения нагрузки на сеть. Если используется, то обязательны для передачи Data, Content-Location, ETag заголовки. Тело ответа при этом статусе не передается.
Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси-сервер, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерироваться ТОЛЬКО серверами-источниками.
Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.
Wikipedia
Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.
Статус 306 использовался в предыдущих версиях спецификации, но больше не используется и код зарезервирован.
Wikipedia
Больше не используется. Раньше обозначал "последующие запросы должны использовать указанный прокси-сервер"
Запрошенный ресурс временно находится по другому URI. Так как перенаправление может быть изменено по какой-либо причине, клиенту следует продолжить использовать Request-URI для последующих запросов. Этот ответ можно закэшировать только в том случае, если это обозначено в заголовках Cache-Control или Expires.
Временный URI СЛЕДУЕТ передать в ответе в поле Location. Если метод запроса не HEAD, в сущность запроса СЛЕДУЕТ включить короткую гипертекстовую заметку со ссылкой на новый (новые) URI, поскольку многие агенты, использующие более ранние протоколы, чем HTTP/1.1, не понимают статус 307. Поэтому заметка ДОЛЖНА содержать информацию, необходимую для пользователя, чтобы повторить запрос на новый URI.
Если статус 307 получен в ответ на запрос, метод которого отличается от GET или HEAD, агент НЕ ДОЛЖЕН автоматически перенаправлять запрос до тех пор, пока он не будет подтвержден пользователем, поскольку это может изменить условия, из-за которых и был сгенерирован этот запрос.
Wikipedia
В этом случае запрос следует повторить на другой URI; как бы то ни было, последующие запросы могут использовать первоначальный URI. В противоположность статусу 302, метод запроса не должен изменяться, когда первоначальный запрос пересоздается. Например, POST-запрос нужно продублировать другим POST-запросом.
Нужно повторить запрос на другой адрес без изменения применяемого метода.
Wikipedia
Этот и все последующие запросы нужно повторить на другой URI. 307 и 308, как было предложено, схожи в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на "постоянно перенаправленный" ресурс можно продолжать без проблем.
4xx: Client Error
Класс кодов 4xx предназначен для определения ошибок, которые произошли на стороне клиента. Кроме случая, когда метод запроса был HEAD, серверу СЛЕДУЕТ включить в ответ сущность, которая содержит в себе объяснение ситуации, которая привела к ошибке, и является ли это временным или постоянным условием. Эти коды применимы к любому методу запроса. Пользовательским агентам СЛЕДУЕТ отображать пользователю включённую в такой ответ сущность.
Если клиент передает данные, то серверу, использующему TCP СЛЕДУЕТ убедиться, что клиент подтверждает отправку пакетов, содержащих ответ, до того, как сервер закроет соединение. Если клиент продолжит отправку данных после того, как сервер закрыл соединение, TCP стек сервера отправит пакет с флагом сброса (TCP reset packet), который может уничтожить клиентские данные, находящиеся в неподтвержденных входных буферах, до того, как они будут прочитаны и обработаны HTTP приложением.
Wikipedia
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
Запрос не удалось обработать из-за синтаксической ошибки. Клиенту НЕ СЛЕДУЕТ повторять такой запрос без изменений.
Wikipedia
Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
Общая ошибка во время выполнения запроса может вызвать неверное состояние. Примером, вызывающим этот статус, может быть ошибка в валидации домена или нехватка данных.
Этот код зарезервирован для использования в будущем.
Wikipedia
Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.
Сервер понял запрос, но отказывается его обрабатывать. Авторизация не поможет и этот запрос НЕ СЛЕДУЕТ повторять. Если метод запроса был HEAD и сервер хочет указать причину, почему запрос не был обработан, то ему СЛЕДУЕТ включить в ответ сообщение с объяснением. Если сервер не хочет, чтобы эта информация была доступна клиенту, вместо кода 403 можно использовать 404.
Wikipedia
Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
Код ошибки используется для ответа пользователю, у которого нет прав для совершения этой операции или если ресурс не доступен по какой-то причине (например, из-за временного ограничения).
Сервер не нашёл по указанному URI никаких ресурсов. Нет никаких указаний о том, постоянное это состояние или нет. СЛЕДУЕТ использовать статус 410 (Gone), если серверу известно, что старый ресурс недоступен постоянно и у него нет адреса пересылки. Этот статус часто используют тогда, когда сервер не хочет обнаруживать истинную причину того, почему он не обработал запрос, или если нельзя применить никакой другой запрос.
Wikipedia
Самая распространённая ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
Используется тогда, когда ресурс не был найден, не существует или был 401, или 403, но из соображений безопасности сервер не ответил этими кодами.
Выполнение метода, определенного в запросе, не разрешено для ресурса, идентифицированного конкретным адресом. Ответ должен содержать Allow заголовок, со списком разрешенных методов для запрашиваемого ресурса.
Wikipedia
Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
Ресурс, определяемый запросом, может только формировать ответы, имеющие характеристики, не совместимые с принятыми заголовками, которые были отправлены в запросе.
Если глагол запроса был не HEAD, в ответ СЛЕДУЕТ включить список доступных характеристик сущности и их места расположения, из которых пользователь или агент пользователя может выбрать наиболее приемлемый вариант. Формат сущности указан в заголовке Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее приемлемого варианта МОЖЕТ происходить автоматически. Как бы то ни было, эта спецификация не определяет каких-либо стандартов для автоматической выборки.
Заметьте: Сервера HTTP/1.1 могут возвращать ответы, неприемлемые для запроса с указанными заголовками. В некоторых случаях предпочтительнее возвращать статус 406. Такое поведение поощряет пользователя проверять заголовки запроса и определять, является ли запрос приемлемым.
Если ответ был не приемлемым, агенту пользователя СЛЕДУЕТ временно прекратить получение других данных и запросить у пользователя решение для дальнейших действий.
Wikipedia
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
Этот код, аналогичен 401 (Unauthorized), но отражает то, что пользователь должен сначала авторизоваться через прокси. Прокси-сервер должен вернуть Proxy-Authenticate заголовок (раздел 14.33), содержащий запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком (раздел 14.34). HTTP доступ рассмотрен в "HTTP Authentication: Basic and Digest Access Authentication"
Wikipedia
Ответ аналогичен коду 401, за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
Клиент не предоставил запрос за то время, пока сервер был готов его ждать. Клиент МОЖЕТ повторить запрос без изменений в любое время.
Wikipedia
Время ожидания сервером передачи от клиента истекло. Клиент может повторить запрос, аналогичный предыдущему, в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должен содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако это не всегда возможно и это не обязательно.
Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.
Wikipedia
Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT. Появился в HTTP/1.1.
Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries and deleting root objects when cascade-delete is not supported are a couple of examples.
Требуемый ресурс больше не доступен на сервере и адрес его расположения неизвестен. Предполагается, что это состояние постоянно. Клиентам с возможностью редактирования ссылки СЛЕДУЕТ удалить ссылки на запрошенный URL после подтверждения. Если сервер не знает, или у него нет возможности определить, постоянно это состояние или нет, СЛЕДУЕТ использовать статус 404 (Not Found). Этот ответ можно кэшировать до тех пор, пока не появится другая информация.
Ответ 410, в первую очередь, предназначен для помощи в оповещении получателей о том, что ресурс умышленно недоступен и что владельцы сервера хотят, чтобы все удаленные ссылки на ресурс были удалены. Такая ситуация обычна для рекламных серверов и для частных ресурсов, владельцы которых больше не поддерживают сайт. Необязательно помечать все постоянно недоступные ресурсы "пропавшими" или сохранять такую пометку на какое-то время — это остаётся на усмотрение владельца.
Wikipedia
Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
Сервер отказывается принять запрос без указания Content-Length. Клиент МОЖЕТ повторить запрос, если добавит корректное значение в поле заголовка Content-Length, которое содержит длину тела сообщения в сообщении запроса.
Wikipedia
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
Предварительное условие, указанное в одном или нескольких заголовках запроса, оказалось ложным, когда оно проверялось на сервере. Этот код ответа позволяет клиенту записывать предварительные условия в метаинформации текущего ресурса, таким образом, предотвращая применение запрошенного метода к ресурсу, кроме того, что ожидается.
Wikipedia
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса.
Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.
Wikipedia
Тело запроса больше, чем сервер может обработать.
Сервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в "чёрную дыру" перенаправлений (например, когда префикс URI указывает на своё же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длиной буфера для чтения или обработки Request-URI.
Wikipedia
Указанный URI был слишком длинным и сервер не смог его обработать.
Сервер отказывается обработать запрос потому, что тело запроса имеет неподдерживаемый запрошенным ресурсом формат.
Wikipedia
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Например, клиент пытается загрузить изображение в формате image/svg+xml, а сервер ожидает другой формат.
Серверу следует вернуть ответ с этим кодом, если запрос содержал поле заголовка Range и ни одно из его значений не совпало с размером выбранного ресурса, при этом в запросе не было поля заголовка If-Range. (Для байтовых диапазонов (byte-range) это означает, что значение first-byte-pos в спецификации byte-range-spec было больше, чем фактический размер выбранного ресурса.)
Когда этот статус возвращается в ответ на запрос с указанием диапазона запрашиваемых байт (byte-range requests), в ответ СЛЕДУЕТ включить поле заголовка сущности Content-Range, в котором указать фактический размер ресурса (см. секцию 14.16). Этот ответ НЕЛЬЗЯ использовать при передаче типа multipart/byteranges.
Wikipedia
Клиент запросил часть файла, но сервер не может её передать. Например, если клиент запросил часть файла, которая находится за пределами конца файла.
Сервер не может удовлетворить значению поля Expect заголовка запроса (см. секцию 14.20), или, если он является прокси-сервером, у него есть однозначное доказательство того, что сервер следующего уровня не сможет удовлетворить этот запрос.
Wikipedia
Сервер не может удовлетворить значению поля Expect заголовка запроса.
Wikipedia
418: Я - чайник
Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами. Как бы то ни было, реализации существуют. HTTP сервер Nginx в своей конфигурации использует этот код для имитации goto-подобного поведения.
Wikipedia
Возвращается Twitter Search и Trends API, когда клиент отправляет слишком много запросов. Вероятно, номер этого кода — отсылка к культуре употребления марихуаны Другие сервисы используют вместо этого кода статус 429 Too Many Requests.
Ответ 422 (Unprocessable Entity) означает, что сервер понимает указанный вид данных, (следовательно, статус 415 (Unsupported Media Type) не подходит), и синтаксис запроса корректен (поэтому статус 400 (Bad Request) не подходит), но содержащиеся в запросе инструкции нельзя выполнить. Например, эта ошибка может возникнуть, если тело запроса было синтаксически правильным, но содержало семантическую ошибку.
Wikipedia
Запрос имел правильный формат, но его нельзя обработать из-за семантических ошибок.
Статус 423 значит, что целевой ресурс недоступен для указанного метода. Этот ответ ДОЛЖЕН содержать соответствующее предусловие или постусловие, например 'lock-token-submitted' или 'no-conflicting-lock'
Wikipedia
Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
Код 424 (Failed Dependency) значит, что метод невозможно применить к ресурсу, потому что запрошенное действие зависело от другого действия, выполнить которое не удалось. Например, если не удалось выполнить команду с методом PROPPATCH, то, как минимум, все остальные запросы завершатся со статусом 424 (Failed Dependency).
Wikipedia
Не удалось завершить запрос из-за ошибок в предыдущем запросе. (например, PROPPATCH)
Slein, J., Whitehead, E.J., и др., "WebDAV Advanced Collections Protocol", Работа в процессе.
Wikipedia
Определен в проекте "WebDAV Advanced Collections Protocol", но не присутствует в "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".
Для надёжного согласования функций обновления с возможностью взаимодействия требуется однозначный сигнал отказа. Код состояния 426 Upgrade Required позволяет серверу окончательно указать, с какими именно расширениями протокола должен обслуживаться данный ресурс.
Wikipedia
Клиенту следует выбрать другой протокол, например такой, как TLS/1.0.
Код состояния 428 указывает, что исходный сервер требует, чтобы запрос был условным.
Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.
Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.
Код состояния 428 не является обязательным; клиенты не могут полагаться на его использование, чтобы предотвратить конфликты "потерянных обновлений".
Wikipedia
Исходный сервер требует, чтобы запрос был условным. Предназначен для предотвращения проблемы "потерянного обновления", когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и отправляет обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту.
Код состояния 429 указывает, что пользователь отправил слишком много запросов за заданный промежуток времени («ограничение скорости»).
Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.
Когда сервер находится под атакой или просто получает очень большое количество запросов от одной стороны, ответ на каждый с кодом состояния 429 потребляет ресурсы.
Следовательно, серверы не обязаны использовать код состояния 429; при ограничении использования ресурсов может быть более целесообразным просто разорвать соединение или предпринять другие шаги.
Wikipedia
Пользователь отправил слишком много запросов за заданный промежуток времени. Предназначен для использования со схемами ограничения скорости.
Код состояния 431 указывает на то, что сервер не желает обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен повторно после уменьшения размера полей заголовка запроса.
Его можно использовать как в случае, когда совокупность полей заголовка запроса слишком велика, так и в случае неисправности одного поля заголовка. В последнем случае представление ответа ДОЛЖНО указывать, какое поле заголовка было слишком большим.
Серверы не обязаны использовать код состояния 431; при атаке может быть более подходящим просто разорвать соединение или предпринять другие шаги.
Wikipedia
Сервер не желает обрабатывать запрос, потому что либо отдельное поле заголовка, либо все поля заголовка в совокупности слишком велики.
Wikipedia
Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)
Wikipedia
Расширение Microsoft. Запрос следует повторить после выполнения соответствующего действия.
Wikipedia
Расширение Microsoft. Эта ошибка возникает, когда родительский контроль Windows включён и блокирует доступ к данной веб-странице.
Wikipedia
Код используется Nginx. Этот код был введен для логирования ситуаций, когда клиент закрывает соединение во время обработки запроса сервером. Таким образом, сервер не может отправить назад заголовок HTTP.
5xx: Server Error
Коды ответов, начинающиеся с "5" указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. Кроме HEAD-запросов, серверу следует включить в ответ сущность, содержащую объяснение ошибки, и является ли это временным или постоянным состоянием. Агентам СЛЕДУЕТ показывать включённую сущность пользователям. Этот код ответа подходит для любых методов запросов.
Wikipedia
Сервер не смог выполнить явно корректный запрос.
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю. Эти коды ответа подходит для любых методов запросов.
Сервер столкнулся с неожиданными условиями, которые не позволили ему обработать запрос.
Wikipedia
Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.
Универсальный код ошибки, когда на стороне сервера произошло исключение.
Сервер не поддерживает функциональных возможностей, необходимых для выполнения запроса. Это типичный ответ, когда сервер не понимает метод в запросе и не способен выполнить запрос для ресурса. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
Wikipedia
Серверу либо неизвестен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос.
Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился для выполнения запроса. Появился в HTTP/1.0.
Wikipedia
Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера.
Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.
Замечание: Некоторые прокси-сервера возвращают 400 или 500, когда время обработки DNS запроса превышает установленный таймаут.
Wikipedia
Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая использовалась в сообщении запроса. Сервер указывает, что он не может или не хочет выполнить запрос, используя ту же основную версию, что и клиент, как описано в разделе 3.1, за исключением этого сообщения об ошибке. Ответ ДОЛЖЕН содержать сущность, описывающую, почему эта версия не поддерживается, и какие другие протоколы поддерживаются этим сервером.
Wikipedia
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
Код состояния 506 указывает на то, что сервер имеет внутреннюю ошибку конфигурации: выбранный вариант ресурса настроен для участия в прозрачном согласовании содержимого и, следовательно, не является надлежащей конечной точкой в процессе согласования.
Wikipedia
В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
Код состояния 507 (Переполнение хранилища) означает, что метод не может быть выполнен для ресурса, поскольку сервер не может сохранить представление, необходимое для успешного выполнения запроса. Это состояние считается временным. Если запрос, получивший этот код состояния, был результатом действия пользователя, запрос НЕ ДОЛЖЕН повторяться до тех пор, пока он не будет запрошен отдельным действием пользователя.
Wikipedia
Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
Код состояния 508 (обнаружен цикл) указывает, что сервер завершил операцию, поскольку он обнаружил бесконечный цикл при обработке запроса с "Depth: infinity". Этот статус указывает на то, что вся операция завершилась неудачно.
Wikipedia
Сервер обнаружил бесконечный цикл при обработке запроса.
Wikipedia
Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
В запросе не соблюдена политика доступа к ресурсу. Сервер должен отправить обратно всю информацию, необходимую клиенту для отправки расширенного запроса. Указание того, как расширения информируют клиента, выходит за рамки данной спецификации.
Если ответ 510 содержит информацию о расширениях, которые не присутствовали в начальном запросе, тогда клиент МОЖЕТ повторить запрос, если у него есть основания полагать, что он может выполнить политику расширений, изменив запрос в соответствии с информацией, предоставленной в ответе 510. В противном случае клиент МОЖЕТ представить пользователю любой объект, включённый в ответ 510, поскольку этот объект может включать в себя релевантную диагностическую информацию.
Wikipedia
На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений
511 код ответа означает, что клиенту необходима авторизация для получения доступа к сети.
Ответ должен содержать ссылку на ресурс, на котором пользователь сможет авторизоваться (например с HTML формой)
Упоминание о том, что 511 ответ не должен содержать требования авторизации или соответствующего интерфейса, потому что браузеры должны будут отобразить интерфейс авторизации, который будет ассоциироваться с запрашиваемым URL, что может путать пользователя.
Статус 511 НЕ ДОЛЖЕН генерироваться исходными серверами; он предназначен для использования путём перехвата прокси-серверов, которые вставляются в качестве средства контроля доступа к сети.
Ответы с кодом состояния 511 НЕ ДОЛЖНЫ храниться в кэше.
Код состояния 511 разработан для смягчения проблем, вызванных «перехватывающими порталами» для программного обеспечения (особенно агентов, не являющихся браузерами), которое ожидает ответа от сервера, к которому был сделан запрос, а не от промежуточной сетевой инфраструктуры. Он не предназначен для поощрения развёртывания скрытых порталов, а только для ограничения наносимого ими ущерба.
Сетевой оператор, желающий потребовать некоторой аутентификации, принятия условий или другого взаимодействия с пользователем перед предоставлением доступа, обычно делает это путём идентификации клиентов, которые этого не сделали ("неизвестные клиенты"), используя свои MAC-адреса.
Неизвестные клиенты затем блокируют весь трафик, за исключением TCP-порта 80, который отправляется на HTTP-сервер ("сервер входа в систему"), предназначенный для «входа в систему» неизвестных клиентов, и, конечно же, трафик на сам сервер входа в систему.
Обычно ответ, содержащий код состояния 511, не поступает от исходного сервера, указанного в URL-адресе запроса. Это создаёт множество проблем с безопасностью; например, атакующий посредник может вставлять файлы cookie в пространство имён исходного домена, может наблюдать файлы cookie или учетные данные HTTP-аутентификации, отправленные пользовательским агентом, и так далее.
Однако эти риски не уникальны для кода состояния 511; другими словами, адаптивный портал, который не использует этот код состояния, вызывает те же проблемы.
Также обратите внимание, что связанные порталы, использующие этот код состояния при подключении SSL или TLS (обычно порт 443), будут генерировать ошибку сертификата на клиенте.
Wikipedia
Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585
Wikipedia
Этот статус не описан в стандарте, однако может быть использован некоторыми HTTP прокси.
Wikipedia
Этот статус не описан в стандарте, однако может быть использован некоторыми HTTP прокси.
* "Top 10" HTTP код ответа. Дополнительная информация о службе REST содержится в записи.