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

Материал из Википедии — свободной энциклопедии

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

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

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With. Также упоминается пояснительная фраза «Reply With»[1] в спецификации по WebDAV в Microsoft Developer Network, введённый Microsoft и 509 Bandwidth Limit Exceeded, введённый в cPanel.

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

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

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

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

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

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

Информационные

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

  • 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • 101 Switching Protocols — Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade. Сервер отправляет заголовок ответа Upgrade, указывая протокол, на который он переключился. Появился в 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.
  • 206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)
  • 207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
  • 208 Already Reported — члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова.
  • 226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Перенаправление

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

По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET или HEAD[7]. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления[16]. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход.

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT)[17]. Чтобы избежать недоразумений, в версии 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.
  • 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 заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).
  • 308 Permanent Redirect — запрашиваемый ресурс был окончательно перенесен на новый URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместо 301-го для избежания неоднозначности. Введено в RFC 7238 (RFC 7538).

Ошибка клиента

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

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

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

  • 403 Forbidden[18] — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Иными словами, клиент не уполномочен совершать операции с запрошенным ресурсом. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401, или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
  • 404 Not Found[19] — самая распространённая ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URL. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
  • 405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
  • 406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
  • 407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
  • 408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
  • 409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.
  • 410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа (например копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
  • 411 Length Required — для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
  • 412 Precondition Failed — возвращается, если ни одно из условных полей заголовка (If-Match и др., см. RFC 7232) запроса не было выполнено. Появился в HTTP/1.1.
  • 413 Payload Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1. Ранее назывался «Request Entity Too Large».
  • 414 URI Too Long — сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1. Ранее назывался «Request-URI Too Long».
  • 415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
  • 416 Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 2409 дней]. Введено в RFC 2616 (обновление HTTP/1.1). Ранее назывался «Requested Range Not Satisfiable».
  • 417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
  • 418 I’m a teapot — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами[20].
  • 421 Misdirected Request — запрос был перенаправлен на сервер, не способный дать ответ.
  • 422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис), однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
  • 423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
  • 424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
  • 426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
  • 428 Precondition Required — сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
  • 429 Too Many Requests — клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
  • 431 Request Header Fields Too Large — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
  • 434 Requested host unavailable — Запрашиваемый адрес недоступен[источник не указан 1846 дней].
  • 449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
  • 451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google[12], при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту». Был добавлен в стандарт 21 декабря 2015[21].

Ошибка сервера

Пример ошибки 502 Bad Gateway

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

  • 500 Internal Server Error[22] — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
  • 501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
  • 502 Bad Gateway — сервер, выступая в роли шлюза или п

Информационные коды состояний HTTP сервера: 100, 101

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. Мы с тобой уже рассмотрели классы кодов состояний HTTP сервера, давай теперь разберем особенности первого класса: это информационные коды состояния HTTP сервера, которые начинаются с единицы. Информационные коды состояния используются для предварительных ответов сервера на запросы клиента.

Информационные коды состояний HTTP сервера: HTTP код 100 и код 101

Общая информация про информационные коды состояния HTTP сервера

Содержание статьи:

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Информационные коды состояний HTTP сервера говорят клиенту о том, что его запрос успешно получен, но еще находится в процессе обработки. Информационные коды состояния еще называют предварительным ответом или временным ответом. Ответ HTTP сервера в этом случае состоит только из строки состояния с кодом состояния и необязательных полей HTTP заголовка.

Давайте сведем в таблицу все информационные HTTP коды состояний и дадим им краткое пояснение.

Информационный код состоянияОписание информационного кода состояния
100 ContinueИнформационный код состояния HTTP сервера  100: продолжай
Код состояния 100 говорит о том, что запрос получен, но находится в процессе обработки
101 Switching ProtocolsИнформационный код состояния HTTP сервера  100: переключи протокол
Код состояния 101 говорит о том, что сервер переключает протокол

HTTP код состояния 100 (продолжать). HTTP код состояния 101 (переключения протоколов)

HTTP код состояния 100 говорит о том, что клиент может продолжать запрос. Ответ сервера, содержащий код 100, является промежуточным и означает то, что начальная часть запроса получена и сервер ждет продолжения.

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

Коды ошибок и статусы | learnapidoc-ru

Toggle navigation

  Курс по документированию API

  • Nav
  • GitHub
  • Original course
  • Feedback

    • ‘,
      noResultsText: »,
      limit: 10,
      fuzzy: true,
      })

    • Learnapidoc-ru 2.0
    • Release notes

      • Release notes
    • Введение в REST API

      • О модуле
      • Коротко о курсе
      • Обзор курса
      • Для чего этот курс
      • Об авторе курса
      • Знакомство с документацией REST API
      • Что такое REST API
      • Видео презентации
      • Презентации курса
      • Практические занятия
      • Практика «Определение цели»
    • Используем API как разработчики

      • О модуле
      • Сценарий использования API сервиса прогноза погоды
      • Получение ключей авторизации

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

    Сервер выполнил часть 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, для возобновления прерванных загрузок
    или для разделения загрузки на несколько параллельных потоков.

    Полное руководство: коды статуса HTTP

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

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

    В этой статье наиболее распространенные коды статуса и коды ошибок.

    Каждый раз, когда вы кликаете по ссылке или вводите URL-адрес и нажимаете «Enter», браузер отправляет запрос на сервер. Он получает и обрабатывает запрос, а затем отправляет обратно запрашиваемые ресурсы вместе с HTTP-заголовком.

    Коды статуса доставляются в браузере в HTTP-заголовке. Хотя вы их не видите. Но когда что-то пошло не так, пользователю отображается код статуса в браузере.Это способ сервера сказать: «Что-то не так. Вот код, который объясняет, что именно ».

    Код статуса HTTP Google 404

    Чтобы увидеть коды статуса, которые браузер обычно не отображает, потребуются специальные инструменты. Для популярных браузеров, таких как Chrome и Firefox, доступны соответствующие расширения. Также существует много сервисов для отображения заголовков, например Web Sniffer.

    увидеть код статуса HTTP с помощью одного из этих инструментов, используя определенную в верхней части отчета, в которой указано: «Статус: HTTP / 1.1 ”. После нее указан код статуса, возвращаемый сервером.

    Коды статуса HTTP разделены на 5:

    • 100: информационные коды, указывающие классы, что запрос, инициированный браузером, продолжается.
    • 200: коды успешного запроса. Возвращаются, когда запрос был успешно получен, распознан и обработан сервером.
    • 300: коды перенаправления возвращаются, когда запрошенный ресурс заменен новым.
    • 400: http-ошибки, обнаруживающие на стороне клиента и указывающие на наличие проблемы с запросом.
    • 500: коды ошибок сервера, указывающие, что запрос был принят, но ошибка на сервере не позволила выполнить его.

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

    200: «Все в порядке». Это код, который возвращается, когда веб-страница или ресурс точно так, как ожидается.

    301: «Запрошенный ресурс был перемещен навсегда».Этот код возвращается, когда веб-страница или ресурс заменяется другим ресурсом. Он используется для постоянного редиректа URL-адресов.

    302: это http-ошибка «Запрошенный ресурс перемещен, но был найден». Этот код используется для указания того, что запрошенный ресурс был найден, но не в том месте, где это ожидалось. Он используется для временного редиректа URL-адресов.

    304: «Запрошенный ресурс не был изменен с момента последнего к нему». Сообщает, что ресурсы, хранящиеся в кэше, не изменились.Он используется для ускорения доставки веб-страниц за счет повторного использования ранее загруженных ресурсов.

    401: «Не авторизован». Возвращается сервером, когда для доступа к целевому ресурсу отсутствуют валидные учетные данные.

    http-ошибка 403: «Доступ к этому ресурсу запрещен». Возвращается, когда пользователь пытается открыть ресурс, для которого у него нет прав доступа. Например, попытка просмотра неавторизованным контентом, защищенным паролем, может привести к ошибке 403.

    404: «Запрошенный ресурс не найден». Наиболее распространенное сообщение об ошибке. Означает, что запрошенный ресурс не существует и сервер не знает, существовал ли он когда-либо.

    405: «Метод не разрешен». Генерируется, когда хостинг-сервер (исходный сервер) поддерживает полученный метод, но целевой ресурс отсутствует.

    406: «Неприемлемый ответ». Запрошенный ресурс генерировать только контент, неприемлемый в соответствии с заголовками Принять, отправленными в запросе.

    408: «Время ожидания сервером поступления остальной части запроса из истекло». Генерируется, когда сервер прерывает обработку после истечения времени ожидания полного запроса от. Другими словами, сервер не получил полный запрос, отправленный браузером. Одной из причин может быть перегрузка сети, приводящая к потере пакетов между браузером и сервером.

    410: «Запрошенный ресурс отсутствует и не будет возвращен». Подобен коду 404 «Не найден», за исключением того, что код статуса 410 указывает, что данный статус ожидается на постоянной основе.

    429: это http-ошибка «Слишком много запросов». Генерируется сервером, когда пользователь отправил слишком много запросов в заданный промежуток времени (ограничение по скорости). Иногда причиной ошибки могут быть боты, пытающиеся получить доступ к сайту. В этом случае может потребоваться изменение URL-адреса входа в панель администрирования WordPress.

    499: «Клиент закрыл запрос». Возвращается NGINX, когда клиент закрывает запрос, пока NGINX все еще обрабатывает его.

    500: «На сервере возникла ошибка, и запрос не мог быть завершен».Общий http-код, который также называют «внутренняя ошибка сервера». На сервере что-то пошло не так и запрошенный ресурс не был доставлен. Этот код генерирует сторонними плагинами, при сбоях PHP-кода или подключения к базе данных.

    501: «Не реализовано». Эта ошибка указывает на то, что сервер не поддерживает функции, необходимые для выполнения запроса. Ошибка почти всегда связана с самим сервером, и для ее решения нужно обратиться к службе поддержки хостинг-провайдера.

    502: это http-ошибка «Некорректный шлюз».Означает, что один сервер получил неверный ответ от другого. Иногда запрос занимает слишком много времени, и поэтому отменяется или удаляется сервером, а соединение с базой данных прерывается.

    503: это http-ошибка «В данный момент сервер не может обработать запрос». Запрос не может быть обработан прямо сейчас. Этот код возвращается перегруженным сервером, который не может обрабатывать новые запросы.

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

    В приведенном выше списке поясняется большинство кодов статуса HTTP, с которым вы можете столкнуться. Вот ресурсы, на которых можно более подробно узнать о редких кодах статуса HTTP, не рассмотренных в нашей статье:

    • Полный список кодов статуса HTTP — Википедия;
    • Определения кодов статуса — Инженерная группа Интернета (IETF);
    • RFC 7231.

    Данная публикация представляет собой перевод статьи «Полное руководство и список кодов состояния HTTP», подготовленной дружной командой проекта Интернет-технологии.ру

    телеграм канал. Подпишись, будет полезно!

    .

    302 Найдено — Веб-технологии для разработчиков

    HTTP-код перенаправления 302 Найдено означает, что запрошенный ресурс был временно перемещен по адресу, указанному в заголовке Местоположение . Получив такой ответ браузер перенаправляет на новую страницу, но поисковые системы не обновляют свои ссылки на ресурс (в жаргоне SEO говорят, что весовые ссылки (ссылка-сок) не меняется и не отправляется на новый URL-адрес).

    Невзирая на требования, указанные в некоторых требованиях по выполнению запроса, не требуется.Поэтому рекомендуется установить код 302 только как ответ для методов GET или HEAD . Для остальных случаев лучше использовать код 307 Temporary Redirect , поскольку в этом случае изменить метод явно запрещено.

    В тех случаях, когда вы хотите, чтобы использовать метод был изменен на GET , використовуйте код 303 См. Другой . Это полезно, если вы хотите дать ответ на метод PUT , который является подтверждающим сообщением (например, «Вы успешно загрузили XYZ»).

    Статус

     302 Найдено 

    Пример

    Запрос клиента

     GET / HTTP / 1.1
    Хост: www.example.org 

    Ответ сервера

     HTTP / 1.1 302 Найдено
    Расположение: http://www.example.org/index.asp 

    Спецификации

    Совместимость с браузером

    Таблица совместимости на этой странице создана на основе структурированных данных. Если вы хотите внести свой вклад в данные, посетите https://github.com/mdn/browser-compat-data и отправьте нам запрос на перенос.

    Обновите данные о совместимости на GitHub

    Компьютеры Мобильные
    Chrome Edge Firefox Internet Explorer Opera Safari Android webview Chrome для Android Firefox для Android Opera для Android Safari на iOS Samsung Internet
    302 Chrome
    Полная поддержка

    Да
    Кромка
    Полная поддержка

    12
    Firefox
    Полная поддержка

    Да
    IE
    Полная поддержка

    Да
    Opera
    Полная поддержка

    Да
    Safari
    Полная поддержка

    Да
    WebView Android
    Полная поддержка

    Да
    Chrome Android
    Полная поддержка

    Да
    Firefox Android
    Полная поддержка

    Да
    Opera Android
    Полная поддержка

    Да
    Safari iOS
    Полная поддержка

    Да
    Samsung Интернет Android
    Полная поддержка

    Да

    Легенда


    Полная поддержка

    Полная поддержка

    Смотрите также

    • 307 Temporary Redirect , эквивалент рассматриваемого кода ответа, но явно запрещающий изменение метода запроса.
    • 303 См. Другое , временное перенаправление, которое изменяет метод запроса на GET .
    • 301 Переехал Постоянно , постоянное перенаправление.

    .