Список кодов состояния HTTP

Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по протоколу HTTP.
Он представляет собой целое трёхразрядное десятичное число. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

  • 201 Created.
  • 401 Unauthorized.
  • 507 Insufficient Storage.

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

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

  • 201 Webpage Created.
  • 507 Insufficient Storage.

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

Список кодов состояния HTTP

(Сообщение закроется через 2 секунды)

Уважаемые дамы и господа!!!

О Б Я З А Т Е Л Ь Н О _ К _ П Р О Ч Т Е Н И Ю ! ! !

Убедительная просьба, прежде чем задать вопрос в конфе и открыть новую тему, поищите ответ на свой вопрос здесь: ССЫЛКА 1,здесь: ССЫЛКА 2 и здесь:ССЫЛКА 3 Я уверен, что 90% ответов вы найдёте по приведённым ссылкам. Также – попробуйте поиск с ГЛАВНОЙ страницы сайта – там могут быть более полные результаты!

P.S Если вам известен код ошибки, то просто “вбейте” его в поисковую строку. И обратите внимание на то, что первая буква кода должна быть набрана в “латинской” раскладке! Иначе результаты поиска вас никуда не приведут.Первая буква кода – НЕ русская буква “Р”!

И еще – ОГРОМНАЯ просьба писать в данном форуме на РУССКОМ языке – поберегите албанский для курилки!!!

1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)

Описание кодов

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

  • 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • 101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
  • 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

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

  • 200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
  • 201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.
  • 202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
  • 203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
  • 204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
  • 205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
  • 207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
  • 226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
Читайте также:  MULTIPLE_IRP_COMPLETE_REQUESTS

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

Поведение клиентов при различных перенаправлениях описано в таблице:

  • 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
  • 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
  • 303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
  • 304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
  • 305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
  • 306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
  • 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

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

  • 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
  • 401 Unauthorized — запрос требует идентификации пользователя. Сервер должен запросить имя и пароль у пользователя, а тот передаст их в заголовке WWW-Authenticate в следующем запросе. Если были указаны неверные данные, то сервер снова вернёт этот же статус. Появился в HTTP/1.0.
  • 402 Payment Required — предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

Список кодов состояния HTTP

Список кодов состояния HTTP

Сервер вернул ошибку 403 при попытке просмотра директории «cgi-bin», доступ к которой был запрещён.

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

  • 500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
  • 501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
  • 502 Bad Gateway — сервер в роли шлюза или прокси-сервера получил сообщение о неудачном выполнении промежуточной операции. Появился в HTTP/1.0.
  • 503 Service Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
  • 504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
  • 505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
  • 506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
  • 507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
  • 509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
  • 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
Читайте также:  Коды ошибок и их участники

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации):

  • Hypertext Transfer Protocol (HTTP) Status Code Registry  . IANA (17 октября 2007). — реестр кодов состояния HTTP. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
  • RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1»  (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (UC Irvine), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), Frystyk Henrik (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)  — обновление протокола HTTP версии 1.1.
  • RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1»  (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (UC Irvine), Gettys Jim (DEC), Mogul J. (DEC), Frystyk Henrik (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
  • RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0»  (русск. «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (UC Irvine), Frystyk Henrik (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации):

  • RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)»  (русск. «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WEBDAV)»); IETF, июнь 2007; Dusseault Ed. L. (CommerceNet) — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
  • RFC 3229 Proposed standard «Delta encoding in HTTP»  (русск. «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
  • RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1»  (русск. «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; Khare Rohit (4K Associates/UC Irvine), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
  • RFC 2774 Experimental «An HTTP Extension Framework»  (русск. «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
  • Internet Draft «WebDAV Advanced Collections Protocol» (русск. «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (UC Irvine), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (FileNet), Crawford J. (IBM), Chihaya T. (DataChannel)  — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
  • RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV»  (русск. «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (UC Irvine), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
  • RFC 2295 Experimental «Transparent Content Negotiation in HTTP»  (русск. «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).
  • Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions  . Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
  • RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)»  (русск. «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
  • KB 318380 Коды состояния служб IIS  . Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Архивировано из первоисточника 17 февраля 2012. Проверено 16 января 2010.
  • Dean Alan. HTTP/1.1 (DELETE, GET, HEAD, PUT, POST)   (23 января 2007). — диаграмма принятия веб-сервером решений об ответе в зависимости от заголовков (схема в формате GIF).(недоступная ссылка — история) Проверено 16 января 2010.
  • Koford Adam. HTTP errors  . Flickr (23 ноября 2006). — иллюстрации кодов ошибок с 400 по 417 для облегчения запоминания посредством мнемотехники. Архивировано из первоисточника 17 февраля 2012. Проверено 16 января 2010.
Читайте также:  Service control manager 7000 загрузка драйвера была заблокирована

СсылкиПравить

  • Hypertext Transfer Protocol (HTTP) Status Code Registry . IANA (17 октября 2007). — реестр кодов состояния HTTP. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
  • RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)  — обновление протокола HTTP версии 1.1.
  • RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (), Gettys Jim (DEC), Mogul J. (DEC), (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
  • RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (), (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.
  • RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)» (англ.) (с  «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WebDAV)»); IETF, июнь 2007; Dusseault Ed. L. () — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
  • RFC 3229 Proposed standard «Delta encoding in HTTP» (англ.) (с  «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
  • RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1» (англ.) (с  «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; (4K Associates/), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
  • RFC 2774 Experimental «An HTTP Extension Framework» (англ.) (с  «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
  • Internet Draft «WebDAV Advanced Collections Protocol» (с  «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (), Crawford J. (IBM), Chihaya T. (DataChannel)  — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
  • RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV» (англ.) (с  «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
  • RFC 2295 Experimental «Transparent Content Negotiation in HTTP» (англ.) (с  «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).
  • Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions . Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
  • RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)» (англ.) (с  «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
  • KB 318380 Коды состояния служб IIS. Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Дата обращения: 16 января 2010. Архивировано 17 февраля 2012 года.
  • Справочник по кодам статуса HTTP. Яндекс. — обработка кодов состояния HTTP роботами Яндекса. Дата обращения: 2 мая 2018.

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

Диаграмма принятия веб-сервером решений на основе заголовков

Статистика по кодам ответа, сгенерированная анализатором логов Webalizer

Обзорный список

Список кодов состояния HTTP

Список кодов состояния HTTP

Статистика по ошибкам HTTP, сгенерированная лог-анализатором AWStats

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *