Коды состояний 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 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100: Continue

Клиент должен продолжать свой Запрос. Этот промежуточный ответ используется для сообщения клиенту о том, что начальная часть запроса была получена и еще не был отвергнут сервером. Клиенту СЛЕДУЕТ продолжить посылку оставшихся данных запроса или, если запрос уже был выполнен, игнорировать этот ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен. См. раздел 8.2.3 для детального обсуждения использования и обработки этого кода состояния.

Wikipedia

Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101: Switching Protocols

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

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

Wikipedia

Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

102: Processing (WebDAV)

Этот промежуточный ответ используется для информирования клиента о том, что сервер принял на себя полную запрос, но еще не завершил ее. Этот статус код должен быть посланы только когда сервер имеет разумные основания ожидать, что запрос займет значительное время. В качестве ориентира, если метод занимает больше времени, чем на 20 секунд (разумно, но произвольное значение) для обработки сервер должен вернуть 102 (Processing) ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен.

Методы потенциально могут занять длительный период времени для процесса, особенно если они поддерживают заголовок Depth. В таких случаях клиент может прервать соединение по тайм-ауту во время ожидания ответа. Чтобы предотвратить это, сервер может вернуть 102 (Processing) код состояния, указывая клиенту, что сервер все еще обрабатывается методом.

Wikipedia

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

2xx: Success

Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят.

Wikipedia

Этот класс кодов состояния указывает на действия, запрошенные клиентом был получен, понят, принят и обработан успешно.

200: OK

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например:

  • GET Получить объект, соответствующий запрошенному ресурсу в ответ;
  • HEAD Поля заголовков, соответствующиe запрошенному ресурсу отправляются в ответ без какого-либо тела сообщения;
  • POST Созданный объект или иной результат действия;
  • TRACE Объект, содержащий сообщение запроса, полученное сервером.

Wikipedia

Стандартный ответ для запросов по HTTP.

Основной код ответа. Обычно используется для того, чтобы показать успешность выполненой операции.

201: Created

Запрос был выполнен, и, в результате, создан новый ресурс. Вновь созданный ресурс может быть, на который ссылается URI (ы) возвращается в объекте ответа, с самым конкретным URI для ресурса отдается в поле заголовка Location. Ответ СЛЕДУЕТ включить объект, содержащий список характеристик и местоположения (ы), из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта определяется тип носителя приведены в Content-Type заголовка поля. Первоначальный сервер ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер должен ответить 202 (Принято) вместо ответа.

A 201 ответа может содержать поля заголовка ETag ответ с указанием текущего значения метки объекта на указанный вариант только что создали, см. раздел 14.19.

Wikipedia

Запрос был выполнен и в результате был создан новый ресурс.

Подтверждение успешного создания (например посредством POST или PUT запроса). Заголовок Location содержит ссылку на только что созданный ресурс (при POST запросе). Тело ответа может быть пустым. Обычно так и бывает.

202: Accepted

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

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

Wikipedia

Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203: Non-Authoritative Information

Предоставленная информация взята не из оригинального источника (а, например, из кеша, который мог устареть, из бекапа, который мог потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предосталвенная информация может совпадать, а может и не совпадать с оригинальными данными.

Wikipedia

Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

Появился в HTTP/1.1.

204: No Content

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

Если клиентом является браузер - то он не должен изменять отображение документа, и его состояние до моента отправки запроса и после этого - не должно изменятья. Этот статус ответа в основном применяется для индикации успешности выполнения запроса с учетом того, что данные и представление данных не должны изменится, не смотря (или с учетом того), что новая (обновленная информация) уже отображена в представлении документа.

204 - должен не содержать тела ответа. Если таковая имеется - она обчно игнорируется и считается что после заголовков присутствет одна пустая линия.

Wikipedia

Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

Статус используется, когда ответ не используется или когда нет контента (например при выполнении команды DELETE)

205: Reset Content

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяетс для возврата в начальное состояние формы ввода данных на клиенте.

Wikipedia

Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206: Partial Content

Сервер выполнил часть 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 (WebDAV)

Код 207 (Multi-Status) позволяет передавать статусы для нескольких независимых операций (за подробностями в секцию 11).

Wikipedia

Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

208: Already Reported (WebDAV)

Относится к DAV и был ранее включен в 207 ответ. Там поныне и остается.

Wikipedia

На сайте отписание отсуствует

226: IM Used

Сервер успешно принял запрос для ресурса и ответ является представлением результата применения одной или нескольких манипуляций с инстансом ресурса. На самом деле актуальне представление ресурса может быть в текущий момент не доступно ввиду того, что действие может быть глобальное и затрагивать несколько инстансов ресурса, а соответственно может комбинироваться с предудущим или возможным в будущем ответом, связанным с специфичными действиями над конкретным инстансом ресурса (или ресусров). Если это так, то при формировании заголовков для конкретного инстанса (или в результирующих заголовках, отталкивающихся от 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. В остальных случаях следующий запрос производить с исходным методом.

300: Multiple Choices

Запрошенный ресурс имеет множество представлений, каждый из которых имеет свое расположение, и для агента по управлению информацией переговоров (раздел 12), представленную таким образом, что пользователь (или агент пользователя) может выбрать наиболее подходящее представление и перенаправить запрос к нему.

Если это не был HEAD запрос, ответ СЛЕДУЕТ включить объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведеных в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако, эта спецификация не определяет никакого стандарта для автоматического выбора.

Если сервер имеет предпочтительный выбор представления, в Location должен быть включен соответствующий URI; агент пользователя может использовать заголовок Location для автоматического редиректа к предложенному ресурсу. Этот запрос может быть закеширован, если явно не было указано иного.

Wikipedia

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301: Moved Permanently

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

Новый постоянный URI должен быть передан в Location заголовке в ответе. Если запрос был не HEAD - в ответе должно содержаться краткое описание того, что адрес изменился с ссылкой на новый адрес. Данная информация должна быть предоставлена в виде HTML.

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

Замечание: Некоторые HTTP/1.0 клиенты, после автоматического редиректа POST запроса, после принятия 301 статуса, ошибочно преобразуют его в GET запрос.

Wikipedia

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302: Found

Запрошенный ресурс временно находится под другим 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.

303: See Other

Документ по запрошенному аресу может быть найден по другому 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

304: Not Modified

Если клиент выполнил условный запрос 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 заголовки. Тело ответа при этом статусе не передается.

305: использовать прокси

Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерировать ТОЛЬКО серверами-источниками.

Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.

Wikipedia

Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.

306: зарезервировано (код использовался только в ранних спецификациях)

Статус 306 использовался в предыдущих версиях спецификации, но больше не используется и код зарезервирован.

Wikipedia

Больше не используется. Раньше обозначал "последующие запросы должны использовать указанный прокси-сервер"

307: Temporary Redirect

Запрошенный ресурс временно находится по другому URI. Так как переадресация может быть изменена по какой-либо причине, клиенту следует продолжить использовать Request-URI для последующих запросов. Этот ответ можно закешировать только в том случае, если это обозначено в заголовках Cache-Control или Expires.

Временный URI СЛЕДУЕТ передать в ответе в поле Location. Если метод запроса не HEAD, в сущность запроса СЛЕДУЕТ включить короткую гипертекстовую заметку со ссылкой на новый (новые) URI, поскольку многие агенты, использующие более ранние протоколы, чем HTTP/1.1, не понимают статус 307. Поэтому пометке СЛЕДУЕТ содержать информацию, необходиную для пользователя, чтобы повторить запрос на новый URI.

Если статус 307 получен в ответ на запрос, метод которого отличается от GET или HEAD, агент НЕ ДОЛЖЕН автоматически перенаправлять запрос до тех пор, пока он не будет подтвержден пользователем, поскольку это может изменить условия, из-за которых и был сгенерирован этот запрос.

Wikipedia

В этом случае запрос следует повторить на другой URI; как бы то ни было, последующие запросы могут использовать первоначальный URI. В противоположность статусу 302, метод запроса не должен изменяться, когда первоначальный запрос пересоздается. Например, POST-запрос нужно продублировать другим POST-запросом.

308: Permanent Redirect (экспериментально)

Нужно повторить запрос на другой адрес без изменения применяемого метода.

Wikipedia

Этот и все последующие запросы нужно повторить на другой URI. 307 и 308, как было предложено, схожи в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на "постоянно перенаправленный" ресурс можно продолжать без проблем.

4xx: Client Error

Класс кодов 4xx предназначен для определения ошибок, которые произошли на стороне клиента. Кроме случая, когда метод запроса был HEAD, серверу СЛЕДУЕТ включить в ответ сущность, которая содержит в себе объяснение ситуации, которая привела к ошибке, и является ли это временным или постоянным условием. Эти коды применимы к любому методу запроса. Пользовательским агентам СЛЕДУЕТ отображать пользователю включенную в такой ответ сущность.

Если клиент передает данные, то серверу, использующему TCP СЛЕДУЕТ убедиться, что клиент подтверждает отправку пакетов, содержащих ответ, до того, как сервер закроет соединение. Если клиент продолжит отправку данных после того, как сервер закрыл соединение, TCP стек сервера отправит пакет с флагом сброса (TCP reset packet), который может уничтожить клиентские данные, находящиеся в неподтвержденных входных буферах, до того, как они будут прочитаны и обработаны HTTP приложением.

Wikipedia

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400: Bad Request

Запрос не удалось обработать из-за синтаксической ошибки. Клиенту НЕ СЛЕДУЕТ повторять такой запрос без изменений.

Wikipedia

Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

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

401: Unauthorized

Запрос требует аунтефикации пользователя. Ответ должен содердать WWW-Authenticate заголовок (раздел 14.47). Клиент может повторить запрос с корректным Authorization заголовком (раздел 14.8). Если запрос уже содержит информацию для авторизации, в таком случае 401 код ответа показывает, что авторизация была отклонена. Если 401, содержит тот же самый вызов, как и предшествующий ответ, а агент пользователя уже делал попытку аутентификации по крайней мере один раз, то СЛЕДУЕТ показать пользователю объект, который был дан в ответе, так как этот объект может включать соответствующую диагностическую информацию. Аутентификации доступа HTTP объясняется в "HTTP-аутентификации: Basic и Digest Authentication Access".

Wikipedia

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

Код используется для пропущенного или не корректного токена аунтефикации.

402: Payment Required

Этот код зарезервирован для использования в будущем.

Wikipedia

Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403: Forbidden

Сервер понял запрос, но отказывается его обрабатывать. Авторизация не поможет и этот запрос НЕ СЛЕДУЕТ повторять. Если метод запросы был HEAD и сервер хочет указать причину, почему запрос не был обработан, то ему СЛЕДУЕТ включить в ответ сообщение с объяснением. Если сервер не хочет, чтобы эта информация была доступна клиенту, вместо кода 403 можно использовать 404.

Wikipedia

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

Код ошибки используется для ответа пользователю, у которого нет прав для совершения этой операции или если ресурс не доступен по какой-то причине (например, из-за временного ограничения).

404: Not Found

Сервер не нашел по указанному URI никаких ресурсов. Нет никаких указаний о том, постоянное это состояние или нет. СЛЕДУЕТ использовать статус 410 (Gone), если серверу известно, что старый ресурс недоступен постоянно и у него нет адреса пересылки. Этот статус часто используют тогда, когда сервер не хочет обнаруживать истинную причину того, почему он не обработал запрос, или если нельзя применить никакой другой запрос.

Wikipedia

Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

Используется тогда, когда ресурс не был найден, не существует или был 401 или 403, но из соображений безопасности сервер не ответил этими кодами.

405: Method Not Allowed

Выполнение метода, определенного в запросе, не разрешено для ресурса, идентифицированного конкретным адресом. Ответ должен содержать Allow заголовок, со списком разрешенных методов для запрашиваемого ресурса.

Wikipedia

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

406: Not Acceptable

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

Если глагол запроса был не HEAD, в ответ СЛЕДУЕТ включить список доступных характеристик сущности и их места расположения, из которых пользователь или агент пользователя может выбрать наиболее приемлемый вариант. Формат сущности указан в заголовке Content-Type. В зависимости от формата и возможнотей агента пользователя, выбор наиболее приемлемого варианта МОЖЕТ происходть автоматически. Как бы то ни было, эта спецификация не определяет каких-либо стандартов для автоматической выборки.

Заметьте: Сервера HTTP/1.1 могут возвращать ответы, неприемлемые для запроса с указанным заголовками. В некоторых случаях предпочтительнее возвращать статус 406. Такое поведение поощряет пользователя проверять заголовки запроса и определять, является ли запрос приемлемым.

Если ответ был не приемлемым, агенту пользователя СЛЕДУЕТ временно прекратить получение других данных и запросить у пользователя решение для дальнейших действий.

Wikipedia

Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407: Proxy Authentication Required

Этот код, аналогичен 401 (Unauthorized), но отражает то, что пользователь должен сначала авторизироваться через прокси. Прокси сервер должен вернуть Proxy-Authenticate заголовок (раздел 14.33), содаржащй запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком (раздел 14.34). HTTP доступ рассмотрен в "HTTP Authentication: Basic and Digest Access Authentication"

Wikipedia

Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408: Request Timeout

Клиент не предоставил запрос за то время, пока сервер был готов его ждать. Клиент МОЖЕТ повторить запрос без изменений в любое время.

Wikipedia

Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409: Conflict

Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должет содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако, это не всегда возможно и это не обязательно.

Как правило, конфликты происходят во время 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.

410: Gone

Требуемый ресурс больше не доступен на сервере и адрес его расположения не известен. Предполагается, что это состояние постоянно. Клиентам с возможностью редактирования ссылки СЛЕДУЕТ удалить ссылки на запрошенный URL после подтверждения. Если сервер не знает, или у него нет возможности определить, постоянно это состояние или нет, СЛЕДУЕТ использовать статус 404 (Not Found). Этот ответ можно кешировать до тех пор, пока не появится другая информация.

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

Wikipedia

Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411: Length Required

Сервер отказывается принять запрос без указания Content-Length. Клиент МОЖЕТ повторить запрос, если добавит корректное значение в поле заголовка Content-Length, которое содержит длину тела сообщения в сообщении запроса.

Wikipedia

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

412: Precondition Failed

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

Wikipedia

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413: Request Entity Too Large

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

Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

Wikipedia

Тело запроса больше, чем сервер может обработать.

414: Request-URI Too Long

Cервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в "черную дыру" редиректов (например, когда префикс URI указывает на свое же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длинной буфера для чтения или обработки Request-URI.

Wikipedia

Укзанный URI был слишком длинным и сервер не смог его обработать.

415: Unsupported Media Type

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

Wikipedia

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Например, клиент пытается загрузить изображение в формате image/svg+xml, а сервер ожидает другой формат.

416: Requested Range Not Satisfiable

Серверу следует вернуть ответ с этим кодом, если запрос содержал поле заголовка Range и ни одно из его значений не совпало с размером выбранного ресурса, при этом в запросе не было поля заголовка If-Range. (Для байтовых диапазонов (byte-range) это означает, что значение first-byte-pos в спецификации byte-range-spec было больше, чем фактический размер выбранного ресурса.)

Когда этот статус возвращается в ответ на запрос с указанием диапазона запрашиваемых байт (byte-range requests), в ответ СЛЕДУЕТ включить поле заголовка сущности Content-Range, в котором указать фактический размер ресурса (см. секцию 14.16). Этот ответ НЕЛЬЗЯ использовать при передаче типа multipart/byteranges.

Wikipedia

Клиент запросил часть файла, но сервер не может ее передать. Например, если клаент запросил часть файла, которая находится за пределами конца файла.

417: Expectation Failed

Сервер не может удовлетворить значению поля Expect заголовка запроса (см. секцию 14.20), или, если сервер - прокси, у него есть однозначное доказательство того, что сервер следующего уровня не сможет удовлетворить этот запрос.

Wikipedia

Сервер не может удовлетворить значению поля Expect заголовка запроса.

418: I'm a teapot (RFC 2324)

Wikipedia

418: Я - чайник

Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами. Как бы то ни было, реализации существуют. HTTP сервер Nginx в своей конфигурации использует этот код для имитации goto-подобного поведения.

420: Enhance Your Calm (Twitter)

Wikipedia

Возвращается Twitter Search и Trends API, когда клиент отправляет слишком много запросов. Вероятно, номер этого кода - отсылка к культуре употребления марихуаны Другие сервисы используют вместо этого кода статус 429 Too Many Requests.

422: Unprocessable Entity (WebDAV)

Ответ 422 (Unprocessable Entity) означает, что сервер понимает указанный вид данных, (следовательно, статус 415(Unsupported Media Type) не подходит), и синтаксис запроса корректен (поэтому статус 400 (Bad Request) не подходит), но содержащиеся в запросе инструкции нельзя выполнитью. Например, эта ошибка может возникнуть, если тело запроса было синтаксически правильным, но содержало семантическую ошибку.

Wikipedia

Запрос имел правильный формат, но его нельзя обработать из-за семантических ошибок.

423: Locked (WebDAV)

Статус 423 значит, что целевой ресурс недоступен для указанного метода. Этот ответ СЛЕДУЕТ содержать соответствующее предусловие или постусловие, например 'lock-token-submitted' или 'no-conflicting-lock'

Wikipedia

Wелевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424: Failed Dependency (WebDAV)

Код 424 (Failed Dependency) значит, что метод невозможно применить к ресурсе, потому что запрошенное действие зависело от другого действия, выполнить которое не удалось. Например, если не удалось выполнить команду с методом PROPPATCH, то, как минимум, все остальные запросы завершатся со статусом 424 (Failed Dependency).

Wikipedia

Не удалось завершить запрос из-за ошибок к предыдущем запросе. (например, PROPPATCH)

425: Reserved for WebDAV

Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", Work In Progress.

Wikipedia

Defined in drafts of "WebDAV Advanced Collections Protocol", but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".

426: Upgrade Required

Надежное, совместимое согласование особенностей обновления требует однозначного сигнала об ошибке. Статус 426 Upgrade Required позволяет серверу окончательно заявить точные расширения протокола, которые нужно использовать для доступа к ресурсу.

Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.

Wikipedia

Клиенту следует выбрать другой протокол, например такой, как TLS/1.0.

428: Precondition Required

The 428 status code indicates that the origin server requires the request to be conditional.

Its typical use is to avoid the "lost update" problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.

Responses using this status code SHOULD explain how to resubmit the request successfully.

The 428 status code is optional; clients cannot rely upon its use to prevent "lost update" conflicts.

Wikipedia

The origin server requires the request to be conditional. Intended to prevent "the "lost update" problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

429: Too Many Requests

The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.

Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes.

431: Request Header Fields Too Large

The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.

It can be used both when the set of request header fields in total are too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.

Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.

444: No Response (Nginx)

Wikipedia

Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)

449: Retry With (Microsoft)

Wikipedia

A Microsoft extension. The request should be retried after performing the appropriate action.

450: Blocked by Windows Parental Controls (Microsoft)

Wikipedia

A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.

451: Unavailable For Legal Reasons
499: Client Closed Request (Nginx)

Wikipedia

Код используется Nginx. Этот код был введен для логирования ситуаций, когда клиент закрывает соединение во время обработки запроса сервером. Таким образом, сервер не может отправить назад заголовок HTTP.

 

5xx: Server Error

Коды ответов, начинающиеся с "5" указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. Кроме HEAD-запросов, серверу следует включить в ответ сущность, содержащую объяснение ошибки, и является ли это временным или постоянным состоянием. Агентам СЛЕДУЕТ показывать включенную сущность пользователям. Этот код ответа подходит для любых методов запросов.

Wikipedia

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

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю. Эти коды ответа подходит для любых методов запросов.

500: Internal Server Error

Сервер столкнулся с неожиданными условиями, которые не позволили ему обработать запрос.

Wikipedia

Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

Универсальный код ошибки, когда на стороне сервера произошло исключение.

501: Not Implemented

Сервер не поддерживает функциональных возможностей, необходимых для выполнения запроса. Это типичный ответ, когда сервер не понимает метод в запросе и не способен выполнить запрос для ресурса. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

Wikipedia

Серверу либо не известен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос.

502: Bad Gateway

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился для выполнения запроса. Появился в HTTP/1.0.

Wikipedia

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера.

503: Service Unavailable

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время извстно, то его МОЖНО передать в заголовке Retry-After. Если заголовок Retry-After передан, то клиенту СЛЕДУЕТ обрабатывать ответ так, как если бы ответом был статус 500.

Замечание: существование кода 503 не обязывает сервер отвечать этим статусом, когда он перегружен. Некоторые сервера просто отвергают соединения.

Wikipedia

Сервер недоступен (из-за перегрузки или технических работ). Обычно это временное состояние.

504: Gateway Timeout

Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.

Замечание: Некоторые прокси-сервера возвращают 400 или 500, когда время обраборки DNS запроса превышает установленный таймаут.

Wikipedia

Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505: HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

Wikipedia

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506: Variant Also Negotiates (Experimental)

The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

Wikipedia

В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507: Insufficient Storage (WebDAV)

The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.

Wikipedia

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

508: Loop Detected (WebDAV)

The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed.

Wikipedia

Сервер обнаружил бесконечный цикл при обработке запроса.

509: Bandwidth Limit Exceeded (Apache)

Wikipedia

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

510: Not Extended

The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.

If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.

Wikipedia

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

511: Network Authentication Required

511 код ответа означает, что клиенту необходима авторизация для получения доступа к сети.

Ответ должен содержать ссылку на ресурс, на котором пользователь сможет авторизоваться (например с HTML формой)

Упоминание о том, что 511 ответ не должен содержать требования авторизации или соответствующего интерфейса, потому что браузеры должны будут отобразить интерфейс авторизации, который будет ассоциироваться с запрашиваемым URL, что может путать пользователя.

The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.

Responses with the 511 status code MUST NOT be stored by a cache.

The 511 status code is designed to mitigate problems caused by "captive portals" to software (especially non-browser agents) that is expecting a response from the server that a request was made to, not the intervening network infrastructure. It is not intended to encouraged deployment of captive portals, only to limit the damage caused by them.

A network operator wishing to require some authentication, acceptance of terms or other user interaction before granting access usually does so by identifing clients who have not done so ("unknown clients") using their MAC addresses.

Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to a HTTP server (the "login server") dedicated to "logging in" unknown clients, and of course traffic to the login server itself.

In common use, a response carrying the 511 status code will not come from the origin server indicated in the request's URL. This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain's name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on.

However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.

Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client.

Wikipedia

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

598: Network read timeout error

Wikipedia

Этот статус не описан в стандарте, однако может быть использован некоторыми HTTP прокси.

599: Network connect timeout error

Wikipedia

Этот статус не описан в стандарте, однако может быть использован некоторыми HTTP прокси.

 

"Top 10" HTTP код ответа. More REST service-specific information is contained in the entry.


Fork me on GitHub