Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по протоколу HTTP.
Он представляет собой целое трёхразрядное десятичное число. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:
201 Webpage Created 403 Access allowed only for registered users 507 Insufficient Storage
Клиент узнаёт по коду ответа о результатах своего запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With
. Также упоминается пояснительная фраза «Reply With» в спецификации по WebDAV в Microsoft Developer Network, введённый Microsoft, и 509 Bandwidth Limit Exceeded
, введённый в cPanel.
Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.
Веб-сервер Internet Information Services в своих файлах журналов, кроме стандартных кодов состояния, использует подкоды, записывая их через точку после основного. При этом в ответах от сервера данный подкод не размещается — он нужен администратору сервера, чтобы тот мог более точно определять источники проблем.
Ниже представлен обзорный список всех описанных в данной статье кодов ответа:
В этот класс выделены коды, информирующие о процессе передачи. При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
Upgrade
. Сервер отправляет заголовок ответа Upgrade
, указывая протокол, на который он переключился. Появился в HTTP/1.1.Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
Location
. Серверу рекомендуется указывать в теле ответа характеристики созданного ресурса и его адреса, формат тела ответа определяется заголовком Content-Type
. При обработке запроса новый ресурс должен быть создан до отправки ответа клиенту, иначе следует использовать ответ с кодом 202
. Появился в HTTP/1.0.200
, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.Content-Range
сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)multistatus
. Не рекомендуется размещать в этом объекте статусы из серии 1xx
из-за бессмысленности и избыточности. Появился в WebDAV.A-IM
от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования. Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301
, 302
, 303
, 305
и 307
относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location
. При этом допускается использование фрагментов в целевом URI.
По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET
или HEAD
. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях, если метод запроса был не HEAD
, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход.
Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301
и 302
ошибочно применяют метод GET
ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303
и 307
и их рекомендовано использовать вместо 302
. Изменять метод нужно только если сервер ответил 303
. В остальных случаях следующий запрос производить с исходным методом.
Поведение клиентов при различных перенаправлениях описано в таблице:
Статус ответа | Кэширование | Если метод не GET или HEAD |
---|---|---|
301 Moved Permanently | Можно как обычно. | Спросить у пользователя подтверждения и запросить другой ресурс исходным методом. |
307 Temporary Redirect | Можно только если указан заголовок Cache-Control или Expires . | |
302 Found (HTTP/1.1)302 Moved Temporarily (HTTP/1.0) | ||
303 See Other | Нельзя. | Перейти автоматически, но уже методом GET . |
Location
заголовка. Если клиент хранит данный URI, то его следует заменить на новый. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.Location
. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые[какие?] клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.Location
заголовка с использованием метода GET
несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с кодом 307
для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET
. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST
, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303
, указав в заголовке Location
его постоянный адрес. Тогда браузер гарантировано его запросит методом GET
для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.GET
, использовал заголовок If-Modified-Since
или If-None-Match
и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.Location
заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.Location
заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303-м вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).Location
заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместо 301-го для избежания неоднозначности. Введено в RFC 7238 (RFC 7538). Класс кодов 4xx
предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD
, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
WWW-Authenticate
с перечнем условий аутентификации. Иными словами, для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization
с требуемыми для аутентификации данными. Если запрос уже включает данные для авторизации, ответ 401 означает, что в авторизации с ними отказано.401
, или 407
при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае серверу следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess
или .htpasswd
) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.404
может использоваться вместо 403
, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.Allow
, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501
(Not Implemented). Появился в HTTP/1.1.HEAD
, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.401
за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.POST
или PUT
. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.PUT
. Появился в HTTP/1.1.Content-Length
в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST
и PUT
. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length
и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.Retry-After
с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1. Ранее назывался «Request Entity Too Large».GET
, а не POST
. Появился в HTTP/1.1. Ранее назывался «Request-URI Too Long».Range
заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range
. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range
заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges
[источник не указан 4415 дней]. Введено в RFC 2616 (обновление HTTP/1.1). Ранее назывался «Requested Range Not Satisfiable».Expect
заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).Upgrade
и Connection
. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.If-Match
. Введено в черновике стандарта RFC 6585.Ms-Echo-Request
. Введено корпорацией Microsoft для WebDAV. В настоящий момент[когда?] используется как минимум программой Microsoft Money. Коды 5xx
выделены под случаи необработанных исключений при выполнении операций на стороне сервера. Для всех ситуаций, кроме использования метода HEAD
, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
405
. Появился в HTTP/1.0.Retry-After
заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After
для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.This article uses material from the Wikipedia Русский article Список кодов состояния HTTP, which is released under the Creative Commons Attribution-ShareAlike 3.0 license ("CC BY-SA 3.0"); additional terms may apply (view authors). Если не указано иное, содержание доступно по лицензии CC BY-SA 4.0. Images, videos and audio are available under their respective licenses.
®Wikipedia is a registered trademark of the Wiki Foundation, Inc. Wiki Русский (DUHOCTRUNGQUOC.VN) is an independent company and has no affiliation with Wiki Foundation.