30.01.

2018 Коды состояний HTTP

Коды состояний HTTP Fork me on GitHub

Данная страница основана на информации о кодах состяний 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

http://www.restapitutorial.ru/httpstatuscodes.html# 1/9
30.01.2018 Коды состояний HTTP
Запрос принят в обработку, но еще не завершен. Нет никаких гарантий, что запрос успешно выполнится в процессе обработки данных. Из-за асинхронного типа
выполняемой операции отсутствует возможность повторной отправки статуса.

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

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 заголовк с тегом для конкретного
инстанса.

http://www.restapitutorial.ru/httpstatuscodes.html# 2/9
30.01.2018 Коды состояний HTTP
Ответ переданный с 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.

http://www.restapitutorial.ru/httpstatuscodes.html# 3/9
30.01.2018 Коды состояний HTTP

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.

http://www.restapitutorial.ru/httpstatuscodes.html# 4/9
30.01.2018 Коды состояний HTTP
Общ ая ошибка во время выполнения запроса может вызвать неверное состояние. Примером, вызывающ им этот статус, может быть ошибка в валидации домена или
нехватка данных.

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

http://www.restapitutorial.ru/httpstatuscodes.html# 5/9
30.01.2018 Коды состояний HTTP
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может
возникнуть при загрузке на сервер объёмного файла методом 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

http://www.restapitutorial.ru/httpstatuscodes.html# 6/9
30.01.2018 Коды состояний HTTP
Клиент запросил часть файла, но сервер не может ее передать. Например, если клаент запросил часть файла, которая находится за пределами конца файла.

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.

http://www.restapitutorial.ru/httpstatuscodes.html# 7/9
30.01.2018 Коды состояний HTTP

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

Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующ их является код 403 Forbidden (сервер понял запрос, но отказывается его
обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже
не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено
несколько вариантов для нового кода, включая "112 Emergency. Censorship in action" и "460 Blocked by Repressive Regime"

Wikipedia
Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения
авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери "451 градус по Фаренгейту".

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)

http://www.restapitutorial.ru/httpstatuscodes.html# 8/9
30.01.2018 Коды состояний HTTP
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.

©Андрей Куманяев, 2012-2014. Все права защ ищены.

Source ©Pearson eCollege, 2012. All rights reserved.

Руководство по REST API

http://www.restapitutorial.ru/httpstatuscodes.html# 9/9