Коды ответа http: 505 HTTP Version Not Supported — HTTP

Содержание

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

Данная страница основана на информации о кодах состояний HTTP. Оригинальными источниками являются ietf.org и Wikipedia. Кликните по заголовку категории или коду состояния для получения подробной информации.

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

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

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

Wikipedia

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

102: Processing (WebDAV)

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

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

Wikipedia

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

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

Wikipedia

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

* 200: OK

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

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

Wikipedia

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

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

* 201: Created

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

Ответ 201 МОЖЕТ содержать поле заголовка ответа ETag, указывающее текущее значение тега объекта для только что созданного запрошенного варианта, см. Раздел 14.19.

Wikipedia

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

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

202: Accepted

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

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

Wikipedia

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

203: Non-Authoritative Information

* 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)

208: Already Reported (WebDAV)

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

Wikipedia

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

226: IM Used

Сервер успешно принял запрос для ресурса и ответ является представлением результата применения одной или нескольких манипуляций с экземпляром ресурса. На самом деле актуальное представление ресурса может быть в текущий момент не доступно ввиду того, что действие может быть глобальное и затрагивать несколько экземпляров ресурса, а соответственно может комбинироваться с предыдущим или возможным в будущем ответом, связанным со специфичными действиями над конкретным экземпляром ресурса (или ресурсов). Если это так, то при формировании заголовков для конкретного экземпляра (или в результирующих заголовках, отталкивающихся от 226 ответа и других экземпляров) нужно руководствоваться частью 13.5.3 спецификации HTTP/1.1.

Запрос обязан содержать в A-IM заголовке перечень как минимум одной манипуляции с экземпляром. Ответ обязан содержать ETag заголовок с тегом для конкретного экземпляра.

Ответ переданный с 226 кодом может быть закэширован и использован в ответах, актуальность которых регулируется Cache-Control заголовком, а также требованиями, которые описаны в секции 10. 6.

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

Wikipedia

Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

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

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

Wikipedia

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

301: Moved Permanently

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

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

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

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

Wikipedia

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

302: Found

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

Временный URI должен быть передан в Location заголовке в ответ на запрос. В случае, если запрос был не HEAD — в ответе должно содержаться упоминание о новом URI в гипертекстовом представлении.

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

Замечание: RFC 1945 и RFC 2068 описывают, что клиенту недопустимо изменять метод исходного запроса при перенаправлении. Тем не менее большинство существующих реализаций User Agent обрабатывает 302 как будто был передан ответ 303, выполняя GET для адреса, переданного в Location, независимо от исходного метода запроса. Статусы 303 и 307 были добавлены для серверов, которым необходимо однозначно понимать, какой вид реакции ожидать от клиента.

Wikipedia

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

303: See Other

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

Новый URI должен быть передан посредством Location в ответе. В случае, если исходный запрос был отличен от HEAD — в ответе должна содержаться ссылка на новый URI в гипертекстовом формате.

Замечание: Многие агенты, до HTTP/1.1 не понимают статуса 303. Когда взаимодействие с такими клиентами является проблемой, код состояния 302 может быть использован вместо 303, так как большинство агентов реагируют на ответ 302, так же как на 303.

Wikipedia

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска.

Введено в HTTP/1.1

* 304: Not Modified

Если клиент выполнил условный запрос GET и доступ разрешен, но документ не был изменен, сервер должен ответить, используя этот код состояния. Ответ 304 НЕ ДОЛЖЕН содержать тела сообщения, и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

Ответ должен содержать следующие заголовки:

  • Дата, если её отсутствия не требует раздел 14.18.1

Если сервер подчиняется этим правилам, и прокси-серверы и клиенты добавят свои собственные Даты к любому ответу, полученному без Даты (как уже указано [RFC 2068], раздел 14. 19), кэши будут работать правильно.

  • ETag и/или Content-Location, если заголовки передаются с 200 кодом ответа.
  • Expires, Cache-Control, и/или Vary, если значения полей изменились с последнего ответа на предыдущие аналогичные запросы.

Если условный GET запрос использует строгую валидацию на присутствие в кэше (см 13.3.3) ответ НЕ должен (желательно) включать другие заголовки. В противном случае ответ НЕ должен (обязательно) включать другие заголовки. Это предотвращает нарушение согласованности данных в кэше и модификации заголовков.

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

Если кэш использует полученный 304 ответ для обновления кэша, кэш ДОЛЖЕН обновить запись, чтобы отразить любые новые значения полей, переданных в ответ.

Wikipedia

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

Используется для условных GET запросов для снижения нагрузки на сеть. Если используется, то обязательны для передачи Data, Content-Location, ETag заголовки. Тело ответа при этом статусе не передается.

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

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

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

Wikipedia

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

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

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

Wikipedia

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

307: Temporary Redirect

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

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

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

Wikipedia

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

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

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

Wikipedia

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

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

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

Wikipedia

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

* 400: Bad Request

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

Wikipedia

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

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

* 401: Unauthorized

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

Wikipedia

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

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

402: Payment Required

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

Wikipedia

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

* 403: Forbidden

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

Wikipedia

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

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

* 404: Not Found

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

Wikipedia

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

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

405: Method Not Allowed

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

Wikipedia

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

406: Not Acceptable

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

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

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

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

Wikipedia

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

407: Proxy Authentication Required

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

Wikipedia

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

408: Request Timeout

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

Wikipedia

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

* 409: Conflict

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

Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.

Wikipedia

Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT. Появился в HTTP/1.1.

Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries and deleting root objects when cascade-delete is not supported are a couple of examples.

410: Gone

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

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

Wikipedia

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

411: Length Required

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

Wikipedia

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

412: Precondition Failed

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

Wikipedia

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

413: Request Entity Too Large

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

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

Wikipedia

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

414: Request-URI Too Long

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

Wikipedia

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

415: Unsupported Media Type

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

Wikipedia

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

416: Requested Range Not Satisfiable

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

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

Wikipedia

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

417: Expectation Failed

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

Wikipedia

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

418: I’m a teapot (RFC 2324)

Wikipedia

418: Я — чайник

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

420: Enhance Your Calm (Twitter)

Wikipedia

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

422: Unprocessable Entity (WebDAV)

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

Wikipedia

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

423: Locked (WebDAV)

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

Wikipedia

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

424: Failed Dependency (WebDAV)

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

Wikipedia

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

425: Reserved for WebDAV

Slein, J., Whitehead, E.J., и др., «WebDAV Advanced Collections Protocol», Работа в процессе.

Wikipedia

Определен в проекте «WebDAV Advanced Collections Protocol», но не присутствует в «Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol».

426: Upgrade Required

Для надёжного согласования функций обновления с возможностью взаимодействия требуется однозначный сигнал отказа. Код состояния 426 Upgrade Required позволяет серверу окончательно указать, с какими именно расширениями протокола должен обслуживаться данный ресурс.

Wikipedia

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

428: Precondition Required

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

Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.

Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.

Код состояния 428 не является обязательным; клиенты не могут полагаться на его использование, чтобы предотвратить конфликты «потерянных обновлений».

Wikipedia

Исходный сервер требует, чтобы запрос был условным. Предназначен для предотвращения проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и отправляет обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту.

429: Too Many Requests

Код состояния 429 указывает, что пользователь отправил слишком много запросов за заданный промежуток времени («ограничение скорости»).

Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.

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

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

Wikipedia

Пользователь отправил слишком много запросов за заданный промежуток времени. Предназначен для использования со схемами ограничения скорости.

431: Request Header Fields Too Large

444: No Response (Nginx)

Wikipedia

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

449: Retry With (Microsoft)

Wikipedia

Расширение Microsoft. Запрос следует повторить после выполнения соответствующего действия.

450: Blocked by Windows Parental Controls (Microsoft)

Wikipedia

Расширение Microsoft. Эта ошибка возникает, когда родительский контроль Windows включён и блокирует доступ к данной веб-странице.

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.

Коды ответов, начинающиеся с «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

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

Wikipedia

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

506: Variant Also Negotiates (Experimental)

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

Wikipedia

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

507: Insufficient Storage (WebDAV)

Код состояния 507 (Переполнение хранилища) означает, что метод не может быть выполнен для ресурса, поскольку сервер не может сохранить представление, необходимое для успешного выполнения запроса. Это состояние считается временным. Если запрос, получивший этот код состояния, был результатом действия пользователя, запрос НЕ ДОЛЖЕН повторяться до тех пор, пока он не будет запрошен отдельным действием пользователя.

Wikipedia

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

508: Loop Detected (WebDAV)

Код состояния 508 (обнаружен цикл) указывает, что сервер завершил операцию, поскольку он обнаружил бесконечный цикл при обработке запроса с «Depth: infinity». Этот статус указывает на то, что вся операция завершилась неудачно.

Wikipedia

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

509: Bandwidth Limit Exceeded (Apache)

Wikipedia

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

510: Not Extended

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

Если ответ 510 содержит информацию о расширениях, которые не присутствовали в начальном запросе, тогда клиент МОЖЕТ повторить запрос, если у него есть основания полагать, что он может выполнить политику расширений, изменив запрос в соответствии с информацией, предоставленной в ответе 510. В противном случае клиент МОЖЕТ представить пользователю любой объект, включённый в ответ 510, поскольку этот объект может включать в себя релевантную диагностическую информацию.

Wikipedia

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

511: Network Authentication Required

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

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

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

Статус 511 НЕ ДОЛЖЕН генерироваться исходными серверами; он предназначен для использования путём перехвата прокси-серверов, которые вставляются в качестве средства контроля доступа к сети.

Ответы с кодом состояния 511 НЕ ДОЛЖНЫ храниться в кэше.

Код состояния 511 разработан для смягчения проблем, вызванных «перехватывающими порталами» для программного обеспечения (особенно агентов, не являющихся браузерами), которое ожидает ответа от сервера, к которому был сделан запрос, а не от промежуточной сетевой инфраструктуры. Он не предназначен для поощрения развёртывания скрытых порталов, а только для ограничения наносимого ими ущерба.

Сетевой оператор, желающий потребовать некоторой аутентификации, принятия условий или другого взаимодействия с пользователем перед предоставлением доступа, обычно делает это путём идентификации клиентов, которые этого не сделали («неизвестные клиенты»), используя свои MAC-адреса.

Неизвестные клиенты затем блокируют весь трафик, за исключением TCP-порта 80, который отправляется на HTTP-сервер («сервер входа в систему»), предназначенный для «входа в систему» неизвестных клиентов, и, конечно же, трафик на сам сервер входа в систему.

Обычно ответ, содержащий код состояния 511, не поступает от исходного сервера, указанного в URL-адресе запроса. Это создаёт множество проблем с безопасностью; например, атакующий посредник может вставлять файлы cookie в пространство имён исходного домена, может наблюдать файлы cookie или учетные данные HTTP-аутентификации, отправленные пользовательским агентом, и так далее.

Однако эти риски не уникальны для кода состояния 511; другими словами, адаптивный портал, который не использует этот код состояния, вызывает те же проблемы.

Также обратите внимание, что связанные порталы, использующие этот код состояния при подключении SSL или TLS (обычно порт 443), будут генерировать ошибку сертификата на клиенте.

Wikipedia

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

598: Network read timeout error

Wikipedia

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

599: Network connect timeout error

Wikipedia

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

* «Top 10» HTTP код ответа. Дополнительная информация о службе REST содержится в записи.

Справочник по кодам статуса HTTP

400Неверный запрос/Bad Request

Запрос не может быть понят сервером из-за некорректного синтаксиса.

401Неавторизованный запрос/Unauthorized

Для доступа к документу необходимо вводить пароль или быть зарегистрированным пользователем.

402Необходима оплата за запрос/Payment Required

Внутренняя ошибка или ошибка конфигурации сервера.

403Доступ к ресурсу запрещен/Forbidden

Доступ к документу запрещен. Если вы хотите, чтобы страница индексировалась, необходимо разрешить доступ к ней.

404Ресурс не найден/Not Found

Документ не существует. Если вы удалили какой-то раздел сайта, можно с помощью robots.txt запретить роботу обращаться к нему. Если такой страницы на сайте никогда не существовало, игнорируйте эту ошибку, возможно, кто-то поставил некорректную ссылку на ваш сайт.

405Недопустимый метод/Method Not Allowed

Метод, определенный в строке запроса (Request-Line), не дозволено применять для указанного ресурса, поэтому робот не смог его проиндексировать.

406Неприемлемый запрос/Not Acceptable

Нужный документ существует, но не в том формате (язык или кодировка не поддерживаются роботом).

407Требуется идентификация прокси, файервола/Proxy Authentication Required

Необходима регистрация на прокси-сервере.

408Время запроса истекло/Request Timeout

Сайт не передал полный запрос в течение установленного времени и робот разорвал соединение.

409Конфликт/Conflict

Запрос конфликтует с другим запросом или с конфигурацией сервера.

410Ресурс недоступен/Gone

Затребованный ресурс был окончательно удален с сайта.

411Необходимо указать длину/Length Required

Сервер отказывается принимать запрос без определенного заголовка Content-Length. Поправьте заголовки на своем сервере;— тогда в следующий раз робот сможет проиндексировать страницу.

412Сбой при обработке предварительного условия/Precondition Failed

При проверке на сервере одного или более полей заголовка запроса обнаружено несоответствие (сбой или ошибка при обработке предварительного условия).

413Тело запроса превышает допустимый размер/Request Entity Too Large

Сервер отказывается обрабатывать запрос потому, что размер запроса больше того, что может обработать сервер.

414Недопустимая длина URI запроса/Request-URI Too Long

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

415Неподдерживаемый MIME тип/Unsupported Media Type

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

416Диапазон не может быть обработан/Requested Range Not Satisfiable

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

417Сбой при ожидании/Expectation Failed

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

422Необрабатываемый элемент/Unprocessable Entity

Сервер не в состоянии обработать один (или более) элемент запроса.

423Заблокировано/Locked

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

424Неверная зависимость/Failed Dependency

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

426Требуется обновление/Upgrade Required

Сервер запросил апгрейд соединения до SSL, но SSL не поддерживается клиентом.

429Слишком много запросов/Too Many Requests

Отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS-атаки. Ответ может сопровождаться заголовком Retry-After, который указывает, через какое время можно повторить запрос. Яндекс не учитывает этот заголовок.

Просмотр кода состояния HTTP — Internet Information Services

  • Статья
  • Чтение занимает 14 мин

В этой статье приводится список кодов состояния протокола HTTP в Microsoft IIS 7.0 или более поздних версий.

Первоначальная версия продукта:   службы IIS версии 7.0 или более поздних версий
Оригинальный номер базы знаний:   943891

Введение

При попытке получить доступ к содержимому на сервере, на котором выполняются службы IIS 7. 0, 7.5 или более поздних версий с помощью протокола HTTP, IIS возвращает числовой код, указывающий на состояние ответа. Код состояния HTTP записывается в журнал IIS. Кроме того, код состояния HTTP может отображаться в клиентском браузере.

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

Расположение файлов журналов

По умолчанию IIS 7.0 или более поздних версий помещает файлы журналов в следующую папку:
inetpub\logs\Logfiles

Данная папка содержит отдельные каталоги для каждого веб-сайта. Файлы журнала создаются в каталогах ежедневно и по умолчанию называются с помощью даты. Пример имени файла журнала: exYYMMDD.log.

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

Примечание

В этой статье не приводится список всех возможных кодов состояния HTTP, предусмотренных в спецификации HTTP. В данной статье перечислены только коды состояния HTTP, которые может отправлять IIS 7.0 или более поздних версий. Например, настраиваемый фильтр ISAPI или настраиваемый модуль HTTP может установить собственный код состояния HTTP.

1

xx — информация

Эти коды состояния HTTP обозначают предварительный ответ. Клиентский компьютер получит один или несколько ответов 1 xx, прежде чем получить обычный ответ.

В IIS 7.0 или более поздних версий используются нижеперечисленные коды состояния HTTP.

  • 100 — продолжение.
  • 101 — смена протоколов.

2

xx — запрос принят

Эти коды состояния HTTP указывают на успешное принятие сервером запроса.

В IIS 7.0 или более поздних версий используются перечисленные ниже коды состояния успеха HTTP.

  • 200 — ОК. Запрос клиента выполнен успешно.
  • 201 — создан.
  • 202 — принято.
  • 203 — недостоверные сведения.
  • 204 — содержимое отсутствует.
  • 205 — сброс содержимого.
  • 206 — частичное содержимое.

3

xx — перенаправление

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

В IIS 7.0 или более поздних версий используются нижеприведенные коды состояния перенаправления HTTP.

  • 301 — перемещено навсегда.
  • 302 — объект перемещен.
  • 304 — объект не изменялся.
  • 307 — временное перенаправление.

4

xx — ошибка клиента

Эти коды состояния HTTP указывают на возникновение ошибки, вероятно, на стороне клиентского браузера. Например, клиентский браузер мог запросить несуществующую страницу. Или не предоставить достоверные сведения для проверки подлинности.

В IIS 7.0 или более поздних версий используются перечисленные ниже коды состояния клиентской ошибки HTTP.

  • 400 — неверный запрос. Серверу не удалось распознать запрос из-за ошибки в синтаксисе. Клиенту не следует повторять запрос без внесения изменений.

    IIS 7.0 или более поздних версий определяет нижеприведенные коды состояния HTTP, которые указывают на более конкретную причину ошибки 400.

    • 400.1 — недопустимый заголовок назначения.
    • 400.2 — недопустимый заголовок глубины.
    • 400.3 — недопустимый заголовок «Если».
    • 400.4 — недопустимый заголовок перезаписи.
    • 400.5 — недопустимый заголовок преобразования.
    • 400.6 — недопустимое тело запроса.
    • 400.7 — недопустимая длина содержимого.
    • 400.8 — недопустимое время ожидания.
    • 400.9 — недопустимый маркер блокировки.
  • 401 — доступ запрещен.

    IIS 7.0 или более поздних версий определяет несколько кодов состояния HTTP, которые указывают на более конкретную причину ошибки 401. Приведенные ниже отдельные коды состояния HTTP отображаются в клиентском браузере, но не отображаются в журнале IIS.

    • 401.1 — ошибка входа.
    • 401.2 — вход не выполнен из-за настройки сервера.
    • 401.3 — доступ запрещен списком управления доступом к ресурсу.
    • 401.4 — доступ запрещен фильтром.
    • 401.5 — авторизация не выполнена из-за приложения ISAPI/CGI.
    • 401.501 — доступ запрещен: слишком много запросов от одного IP-адреса клиента; достигнут предел скорости одновременно выполняемых запросов в рамках динамического ограничения IP-адресов.
    • 401.502 — запрещено: слишком много запросов от одного IP-адреса клиента; достигнут максимальный предел скорости запросов в рамках динамического ограничения IP-адресов.
    • 401.503 — доступ запрещен: IP-адрес включен в запрещающий список ограничения IP-адресов
    • 401.504 — доступ запрещен: имя узла включено в запрещающий список ограничения IP-адресов
  • 403 — запрет.

    IIS 7.0 или более поздних версий определяет приведенные ниже коды состояния HTTP, которые указывают на более конкретную причину ошибки 403.

    • 403.1 — доступ на выполнение запрещен.
    • 403.2 — доступ на чтение запрещен.
    • 403.3 — доступ на запись запрещен.
    • 403.4 — требуется SSL.
    • 403.5 — требуется SSL 128.
    • 403.6 — IP-адрес отклонен.
    • 403.7 — требуется сертификат клиента.
    • 403.8 — отказ в доступе к узлу.
    • 403.9 — запрещено: слишком много клиентов пытается подключиться к веб-серверу.
    • 403.10 — запрещено: настройками веб-сервера запрещен доступ для выполнения.
    • 403.11 — запрещено: пароль был изменен.
    • 403.12 — отказ доступа от программы сопоставления.
    • 403.13 — сертификат клиента отозван.
    • 403.14 — вывод каталогов запрещен.
    • 403.15 — запрещено: превышен лимит доступа клиентов на веб-сервере.
    • 403.16 — сертификат клиента недействителен либо не является доверенным.
    • 403.17 — срок действия сертификата клиента истек, либо сертификат еще не вступил в силу.
    • 403.18 — запрос указанного URL-адреса не может быть выполнен в текущем пуле приложений.
    • 403.19 — невозможно выполнять приложения CGI для этого клиента в данном пуле приложений.
    • 403.20 — запрещено: вход систему с помощью служб Passport не выполнен.
    • 403.21 — запрещено: доступ к источнику запрещен.
    • 403.22 — запрещено: неограниченная глубина запрещена.
    • 403.501 — запрещено: слишком много запросов от одного IP-адреса клиента; достигнут предел скорости одновременно выполняемых запросов в рамках динамического ограничения IP-адресов.
    • 403.502 — запрещено: слишком много запросов от одного IP-адреса клиента; достигнут максимальный предел скорости запросов в рамках динамического ограничения IP-адресов.
    • 403.503 — запрещено: IP-адрес включен в запрещающий список ограничения IP-адресов
    • 403.504 — запрещено: имя узла включено в запрещающий список ограничения IP-адресов
  • 404 — объект не найден.

    IIS 7.0 или более поздних версий определяет нижеперечисленные коды состояния HTTP, которые указывают на более конкретную причину ошибки 404.

    • 404,0 — объект не найден.

    • 404.1 — сайт не найден

    • 404.2 — ограничение ISAPI или CGI.

    • 404.3 — ограничение типа MIME.

    • 404.4 — обработчик не настроен.

    • 404.5 — запрещено конфигурацией фильтрации запросов.

    • 404.6 — команда отклонена.

    • 404.7 — расширение имени файла отклонено.

    • 404.8 — скрытое пространство имен.

    • 404.9 — атрибут файла скрыт.

    • 404.10 — превышена допустимая длина заголовка запроса.

    • 404.11 — запрос содержит последовательность двойного преобразования символов.

    • 404.12 — запрос содержит знаки расширенного набора.

    • 404.13 — превышен лимит длины содержимого.

    • 404.14 — превышена допустимая длина URL-адреса запроса.

    • 404.15 — строка запроса слишком длинная.

    • 404.16 — запрос DAV передан обработчику файла статистики.

    • 404.17 — динамическое содержимое сопоставлено обработчику файла статистики с помощью сопоставления MIME с подстановочными знаками.

    • 404.18 — последовательность строк запросов отклонена.

    • 404.19 — запрещено правилом фильтрации.

    • 404.20 — слишком много сегментов URL-адреса

    • 404.501 — не найдено: слишком много запросов от одного IP-адреса клиента; достигнут предел скорости одновременно выполняемых запросов в рамках динамического ограничения IP-адресов.

    • 404.502 — не найдено: слишком много запросов от одного IP-адреса клиента; достигнут максимальный предел скорости запросов в рамках динамического ограничения IP-адресов.

    • 404.503 — не найдено: IP-адрес включен в запрещающий список ограничения IP-адресов

    • 404.504 — не найдено: имя узла включено в запрещающий список ограничения IP-адресов

    • 405 — метод запрещен.

    • 406 — браузером клиента не принимается тип MIME запрашиваемой страницы.

    • 408 — истекло время ожидания запроса.

    • 412 — необходимое условие не выполнено.

5

xx — ошибка сервера

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

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

  • 500 — внутренняя ошибка сервера.

    IIS 7.0 или более поздних версий определяет перечисленные ниже коды состояния HTTP, которые указывают на более конкретную причину ошибки 500.

    • 500.0 — ошибка модуля или ISAPI.

    • 500.11 — приложение на веб-сервере закрывается.

    • 500.12 — приложение на веб-сервере перезапускается.

    • 500.13 — веб-сервер перегружен.

    • 500.15 — прямые запросы для Global.asax запрещены.

    • 500.19 — недопустимые данные конфигурации.

    • 500.21 — модуль не распознан.

    • 500.22 — конфигурация ASP.NET httpModules не применяется в режиме управляемого конвейера.

    • 500.23 — конфигурация ASP.NET httpHandlers не применяется в режиме управляемого конвейера.

    • 500.24 — конфигурация олицетворения ASP.NET не применяется в режиме управляемого конвейера.

    • 500.50 — при обработке уведомления RQ_BEGIN_REQUEST произошла ошибка перезаписи. Возникла ошибка конфигурации или выполнения правила для входящего трафика.

      Примечание

      Здесь конфигурация распределенных правил считывается как для входящих, так и для исходящих правил.

    • 500.51 — при обработке уведомления GL_PRE_BEGIN_REQUEST произошла ошибка перезаписи. Возникла ошибка глобальной конфигурации или выполнения глобального правила.

      Примечание

      Здесь считывается конфигурация глобальных правил.

    • 500.52 — при обработке уведомления RQ_SEND_RESPONSE произошла ошибка перезаписи. Произошло выполнение правила для исходящего трафика.

    • 500.53 — при обработке уведомления RQ_RELEASE_REQUEST_STATE произошла ошибка перезаписи. Произошла ошибка выполнения правила для исходящего трафика. Правило настроено на выполнение до обновления пользовательского кэша вывода.

    • 500.100 — внутренняя ошибка ASP.

  • 501 — значения, указанные в заголовке, определяют нереализованную конфигурацию.

  • 502 — веб-сервером в качестве шлюза или прокси-сервера получен недопустимый ответ.

    IIS 7.0 или более поздних версий определяет нижеприведенные коды состояния HTTP, которые указывают на более конкретную причину ошибки 502.

    • 502.1 — истекло время ожидания приложения CGI.
    • 502.2 — недопустимый шлюз: преждевременный выход.
    • 502.3 — недопустимый шлюз: ошибка подключения к серверу пересылки (ARR).
    • 502.4 — недопустимый шлюз: сервер отсутствует (ARR).
  • 503 — служба недоступна.

    IIS 7.0 или более поздних версий определяет приведенные ниже коды состояния HTTP, которые указывают на более конкретную причину ошибки 503.

    • 503.0 — пул приложений недоступен.
    • 503.2 — достигнут предел одновременно выполняемых запросов.
    • 503.3 — очередь ASP.NET переполнена
    • 503.4 — очередь FastCGI переполнена

В нижеприведенной таблице описаны причины отображения некоторых распространенных кодов состояния HTTP.

КодОписаниеПримечания
200OKЗапрос успешно обработан IIS 7.0 или более поздних версий.
304Не измененоКлиентский браузер запрашивает документ, который уже находится в кэше. И документ не был изменен с момента своего кэширования. Клиентский браузер использует кэшированную копию документа вместо скачивания его с сервера.
400Недопустимый запросФайл стека протокола HTTP (Http. sys) препятствует обработке запроса службами IIS 7.0 или более поздних версий из-за проблемы в запросе. Обычно этот код состояния HTTP означает, что запрос содержит недопустимые символы или последовательности или же противоречит параметрам безопасности в файле Http.sys.
401.1Ошибка входа в системуБезуспешная попытка входа в систему, вероятно, из-за недопустимого имени пользователя или пароля.
401.2Вход не выполнен из-за настройки сервераЭтот код состояния HTTP указывает на проблему в параметрах конфигурации проверки подлинности на сервере.
401.3Доступ запрещен списком управления доступом к ресурсуЭтот код состояния HTTP указывает на проблему в разрешениях файловой системы NTFS. Эта проблема может возникать, даже если разрешения для файла, к которому вы пытаетесь получить доступ, установлены правильно. Например, эта ошибка возникает, если у учетной записи IUSR отсутствуют права доступа к каталогу C:\Winnt\System32\Inetsrv.
401.4Авторизация не выполнена из-за фильтраФильтр ISAPI препятствует обработке запроса из-за проблемы с авторизацией.
401.5Авторизация не выполнена из-за приложения ISAPI/CGIПриложение ISAPI или приложение CGI препятствуют обработке запроса из-за проблемы с авторизацией.
403.1Доступ на выполнение запрещенНе предоставлен соответствующий уровень разрешения на выполнение.
403.2Доступ на чтение запрещенНе предоставлен соответствующий уровень разрешения на чтение. Убедитесь, что службы IIS 7.0 или более поздних версий настроены на предоставление разрешения на чтение для каталога. Кроме того, если используется документ по умолчанию, убедитесь, что данный документ существует.
403.3Доступ на запись запрещенНе предоставлен соответствующий уровень разрешения на запись. Проверьте разрешения IIS 7.0 и более поздних версий и разрешения файловой системы NTFS. Убедитесь, что они настроены для предоставления каталогу разрешения на запись.
403.4Требуется SSLЗапрос выполнен по небезопасному каналу. Но для веб-приложения требуется подключение SSL.
403.5Требуется SSL 128Сервер настроен на требование 128-битного SSL-соединения. Но запрос не был отправлен с использованием 128-битного шифрования.
403.6IP-адрес отклоненСервер настроен на запрет доступа к текущему IP-адресу.
403.7Требуется сертификат клиентаСервер настроен на требование сертификата для проверки подлинности клиента. Но в клиентском браузере не установлен соответствующий сертификат клиента. Дополнительные сведения см. в статье Ошибка HTTP 403.7 при запуске веб-приложения, размещенного на сервере, на котором выполняется IIS 7.0.
403.8Нет доступа к сайтуСервер настроен на отклонение запросов на основе DNS-имени клиентского компьютера. Дополнительные сведения см. в статье Динамическое ограничение IP-адресов.
403.12Доступ запрещен модулем сопоставленияДоступ к странице возможен только при наличии сертификата клиента. Но идентификатору пользователя, сопоставленному с сертификатом клиента, отказано в доступе к файлу.
403.13Сертификат клиента отозванКлиентский браузер пытается использовать сертификат клиента, отозванный выдающим центром сертификации.
403.14Вывод каталогов запрещенСервер не настроен для отображения списков каталогов содержимого, и не установлен документ по умолчанию. Дополнительные сведения см. в статье Ошибка «HTTP 403.14 — Запрещено» при открытии веб-страницы IIS.
403.16Сертификат клиента недействителен либо не является доверенным.Клиентский браузер пытается использовать недействительный клиентский сертификат. Или сервер, на котором запущены IIS 7.0 и более поздние версии, не доверяет клиентскому сертификату. Дополнительные сведения см. в статье Ошибка HTTP 403.16 при попытке получения доступа к размещенному на IIS 7.0 веб-сайту.
403.17Срок действия сертификата клиента истек, либо сертификат еще не вступил в силу.Клиентский браузер пытается использовать сертификат клиента, срок действия которого истек, или сертификат, который еще не вступил в силу.
403.18Запрос указанного URL-адреса не может быть выполнен в текущем пуле приложенийНастраиваемая страница ошибки настроена. И пул приложений страницы ошибки клиента отличается от пула приложений запрашиваемого URL-адреса.
403.19Невозможно выполнять приложения CGI для этого клиентского браузера в данном пуле приложений.Удостоверение пула приложений не имеет права пользователя на замену маркера уровня процесса.
404.0Не найдено.Файл, к которому вы пытаетесь получить доступ, был перемещен или не существует.
404.2Ограничение ISAPI или CGI.На компьютере ограничен доступ к запрашиваемому ресурсу ISAPI или запрашиваемому ресурсу CGI. Дополнительные сведения см. в статье Ошибка HTTP 404.2 при посещении веб-страницы, размещенной на компьютере, на котором выполняется IIS 7.0.
404.3Ограничение типа MIME.Текущее сопоставление MIME для запрашиваемого типа расширения недействительно или не настроено.
404.4Обработчик не настроен.У расширения имени файла запрашиваемого URL-адреса нет обработчика, настроенного на обработку запроса на веб-сервере.
404.5Запрещено конфигурацией фильтрации запросов.Запрашиваемый URL-адрес содержит последовательность символов, которая блокируется сервером.
404.6Команда отклонена.Запрос отправлен с помощью ненастроенной или недействительной HTTP-команды.
404.7Расширение имени файла отклонено.Запрашиваемое расширение имени файла запрещено.
404.8Скрытое пространство имен.Использование запрашиваемого URL-адреса запрещено, поскольку каталог скрыт.
404.9Атрибут файла скрыт.Запрашиваемый файл скрыт.
404.10Превышена допустимая длина заголовка запроса.Запрос отклонен из-за превышения допустимой длины его заголовка.
404.11Запрос содержит последовательность двойного преобразования символов.Запрос содержит последовательность двойного преобразования символов.
404.12Запрос содержит знаки расширенного набора.Запрос содержит знаки расширенного набора, а сервер настроен на запрещение их использования.
404.13Превышен лимит длины содержимого.Запрос содержит заголовок Content-Length. Значение заголовка Content-Length превышает допустимый для сервера предел. Дополнительные сведения см. в статье Сообщение «Ошибка HTTP 404.13 — CONTENT_LENGTH_TOO_LARGE» при посещении веб-сайта, размещенного на сервере, на котором выполняется IIS 7.0.
404.14Превышена допустимая длина URL-адреса запроса.Длина запрашиваемого URL-адреса превышает допустимый для сервера предел.
404.15Строка запроса слишком длинная.Запрос содержит строку запроса, которая превышает допустимый для сервера предел.
404.17Динамическое содержимое сопоставлено обработчику файла статистики.Дополнительные сведения см. в статье Сообщение «Ошибка HTTP 404.17 — не найдено» при посещении веб-сайта, размещенного на IIS 7.0.
405.0Метод запрещен.Запрос отправлен с помощью недействительного метода HTTP. Дополнительные сведения см. в статье Ошибка HTTP 405.0 при посещении веб-сайта, размещенного на сервере, на котором выполняется IIS.
406. 0Недопустимый тип MIME.Запрос отправлен с помощью заголовка Accept, который содержит недействительное значение MIME.
412.0Необходимое условие не выполнено.Запрос отправлен с помощью заголовка If-Match, который содержит недействительное значение.
500Внутренняя ошибка сервера.Этот код состояния HTTP может возникать по многим причинам на стороне сервера. Дополнительные сведения см. в статье Сообщение «Ошибка HTTP 500.0 — внутренняя ошибка сервера» при открытии веб-страницы IIS 7.0.
500.11Приложение на веб-сервере закрывается.Обработка запроса не осуществляется из-за закрытия конечного пула приложений. Дождитесь завершения рабочего процесса закрытия, а затем повторите запрос. Если проблема не исчезнет, возможно, в веб-приложении возникли ошибки, которые препятствуют его правильному закрытию.
500.12Приложение на веб-сервере перезапускается.Обработка запроса не осуществляется из-за перезапуска конечного пула приложений. После обновления страницы данный код состояния HTTP должен исчезнуть. Если этот код состояния HTTP появится снова после обновления страницы, проблема может быть вызвана антивирусной программой, которая сканирует файл Global.asa. Если проблема не исчезнет, возможно, в веб-приложении возникли ошибки, которые препятствуют его правильному перезапуску.
500.13Веб-сервер перегружен.Обработка запроса не осуществляется, поскольку сервер перегружен и не может принимать новые входящие запросы. Обычно этот код состояния HTTP означает, что количество одновременно выполняемых входящих запросов превышает количество, которое может обрабатывать веб-приложение IIS 7.0 или более поздних версий. Эта проблема может появиться из-за слишком низких параметров конфигурации производительности, недостаточности оборудования или возникновения узкого места в веб-приложении IIS 7.0 или более поздних версий. Распространенным методом устранения неполадок является создание файла дампа памяти процессов IIS 7.0 или более поздних версий при возникновении ошибки и последующая отладка файла дампа памяти.
500.15Прямые запросы для Global.asax запрещены.Сделан прямой запрос на файл Global.asa или файл Global.asax.
500.19Недопустимые данные конфигурации.Этот код состояния HTTP возникает из-за проблемы в связанном файле applicationhost.config или связанном файле Web.config. Дополнительные сведения см. в статье Ошибка HTTP 500.19 при открытии веб-страницы IIS.
500.100Внутренняя ошибка ASP.Ошибка возникает при обработке страницы ASP. Чтобы получить более конкретную информацию об этой ошибке, отключите вывод подробных сообщений об ошибках HTTP в веб-браузере. Кроме того, в журнале IIS может отображаться номер ошибки ASP, соответствующий возникшей ошибке.
503. 0Служба недоступна.Запрос отправлен в пул приложений, который в настоящее время остановлен или отключен. Для устранения этой проблемы необходимо убедиться, что конечный пул приложений запущен. В журнале событий могут содержаться сведения о том, почему пул приложений остановлен или отключен.
503.2Превышено максимально допустимое количество одновременно выполняемых запросов.Для свойства appConcurrentRequestLimit установлено значение, которое меньше текущего количества одновременно выполняемых запросов. IIS 7.0 или более поздних версий не допускает одновременное выполнение запросов, количество которых превышает значение свойства appConcurrentRequestLimit.
Дополнительный кодОписание
400.10Недействительный заголовок XFF
400.11Недействительный запрос WebSocket
Дополнительный кодОписание
400. 601Недопустимый запрос клиента (ARR)
400.602Недопустимый формат времени (ARR)
400.603Ошибка диапазона анализа (ARR)
400.604Клиент потерян (ARR)
400.605Достигнуто максимальное количество пересылок (ARR)
400.606Ошибка асинхронного соревнования (ARR)
502.2Сбой запроса на сопоставление (ARR)
502.3Ошибка асинхронного соревнования WinHTTP (ARR)
502.4Сервер отсутствует (ARR)
502.5Сбой WebSocket (ARR)
502.6Сбой перенаправленного запроса (ARR)
502.7Сбой запроса на выполнение (ARR)

Ссылки

Дополнительные сведения об определениях кодов состояния HTTP см. на странице HTTP/1.1: определения кодов состояния.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Список кодов состояния HTTP + их значение для SEO

Довольно часто вы можете столкнуться с такими ошибками, как 404 и 301, но есть много кодов статуса HTTP, с которыми вы, вероятно, не знакомы.

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

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

100301405417450
101302406418451
102303407422500
200304408423501
201305409424502
202306410425503
203307411426504
204400412428505
205401413429506
206402414431507
207403415444509
300404416449510

1xx информационные коды

100 Continue Server Code (Продолжение кода сервера)
Код 100 Continue обозначает «нормальную работу». Он указывает, что пользователь сделал качественный запрос, и сервер начал его обрабатывать. Это временный код статуса HTTP, появляющийся лишь в тех отдельных случаях, когда пользователь ожидает окончательный ответ со стороны сервера. Он возникает только после отправки последнего пакета данных.

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

101 Switching Protocols (Переключение протоколов)
Вероятно, это один из простейших кодов сервера. Он означает, что пользователь попросил переключить используемый тип протокола, и веб-сервер согласился на такой шаг.
Когда вы можете его применить? Если осуществляется переход на новую версию HTTP из старой версии протокола. Такой запрос будет выполняться только в том случае, если существует более подходящий протокол (другими словами, если есть более новая версия HTTP).

102 Processing (Обработка)
Поскольку запрос WebDAV (протокол передачи), кроме основного запроса может включать и ряд других подзапросов, подразумевая также и файловые операции, то для его выполнения может потребоваться больше времени.
Когда можно использовать этот код? Он создается для того, чтобы уведомить пользователя и обнулить таймер. Дальше будет активировано ожидание следующей директивы в стандартном режиме, поскольку обработка запросов способна затянуться по времени.

2xx Success (Успех)

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

200 OK
Код состояния 200, наверное, является наиболее популярным, но в то же время очень неприметным в плане использования. Он указывает, что передача данных между сервером и пользователем подошла к завершению, и все прошло так, как должно.
Когда этот код нужно использовать? Постоянно!

201 Created (Создан)
В связи с успешным выполнением запроса создался новый ресурс. К примеру, благодаря запросу юзера сгенерирован такой ранее не существующий веб-ресурс, как новая страница. Исходной сервер настроен так, что обязан создать ресурс еще до отправки 201 кода. Если документ не может быть сгенерирован своевременно, сервер использует в качестве альтернативы код 202 (принят).

202 Accepted (Принят)
Текущий запрос был передан в стадию обработки, но в силу объективных факторов является незавершенным. Запрос к серверу может быть не завершенным, это зависит от факта, успешно ли прошла обработка и не отклонили ли его.

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

203 Non-Authoritative Information (Недостоверная информация)
Серверу удалось полностью обработать запрос, но передаваемые данные не были взяты из первостепенного источника (резервная копия, другой сервер и т. д.) и поэтому информация может быть нерелевантной. Этот код имеет большое сходство с 200 серверным ответом, но указывает, что данные не были получены из источника.

Когда применяют подобный ответ сервера? Ним можно заменить 200 код, если отправитель имеет веские основания полагать, что заголовки ответов из внешнего источника отличаются от тех, которые были предоставлены исходным сервером.

204 No Content (Нет контента)
Этот код является ответом сервера, который указывает, что запрос получили и поняли. Но при этом не существует данных, которые могут быть отправлены пользователю. В основном такой код используется для активации скриптов без необходимости внесения изменений в веб-документ. Нужно, чтобы указанный код не содержал основного сообщения, и он должен быть вставлен в первую строку с кодом, которая является доступной сразу после заголовка.

Когда применяется такой код? Он используется в первую очередь, когда вы должны вводить или выполнять любые действия без необходимости в обновлении ресурса (например, страницы).

205 Reset Content (Сброс контента)
Код обозначает успешную обработку запроса сервером c отсутствующим возвратом контента. В отличие от 204 кода, этот ответ требует, чтобы документ был обновлен.

Когда может применяться такой код? Обычно он используется в случаях, заполнения пользователем формы, и отправки сервером браузеру запроса на очистку этой формы. Он имеет сходство с 204 кодом, но выдвигает требование к пользователю по сбросу документа после завершения обработки. К примеру, требуется провести очистку HTML-формы после верификации.

206 Partial Reset (Частичный сброс)
Сервер возвращает только часть контента, которая соответствует заголовку, отправленному клиентом. В основном его используют расширенные инструменты кэширования. Такое бывает, когда пользователь хочет получить лишь небольшую часть контента страницы, а сервер в своем ответе предоставляет данные только для этой части страницы.

Каковы способы применения этого кода? Преимущественно этот код используется из-за запроса If-Range, применимого в мощных кеш-валидаторах. Обращение также должно включать заголовки областей, которые используются в качестве параметров для области возвращаемой информации.

207 Multi-Status (Мультистатус)
Сервер параллельно предоставляет результаты нескольких независимых операций, которые включаются в тело сообщения в виде XML-документа.

3xx Редирект

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

300 Multiple Choices (Множественный выбор)

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

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

301 Moved Permanently (Удален навсегда)
Это общий запрос пользователя, который означает, что запросы на этот ресурс (а также запросы, которые последуют за ним) следует перенаправить на указанный URL.

Когда он используется? Когда страница потеряна, больше не существует, или линк, ведущий на внешний документ, больше неработоспособен. 301 редирект дает пользователю понять, что запрошенный ресурс переместили. В основном он выполняется с помощью файла .htaccess, который доступен на серверах Apache.

302 Found (Найден)
Этот код говорит пользователю, что местоположение запрашиваемого веб-документа было временно изменено, а код состояния 302 включает данные о новом размещении, к которому пользователь может делать запрос.

Где такой код может применяться? Он имеет несколько форматов использования, большинство из которых соответствуют первоначальному предназначению кода. А вначале он был базовым методом создания временной переадресации. Однако, на сегодняшний день существует несколько других – этичных и неэтичных способов его использования.

303 See Other (Смотреть другой)
Он является индикатором того, что искомый ресурс можно найти по URL-адресу, который отличный от того, что указан в запросе. Это не обязательно значит, что ресурс был перемещен. Этот код только предоставляет адрес, который должен запрашиваться при аналогичном ответе.

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

304 Not Modified (Не изменен)
304 означает, что пользователь запрашивает документ / ресурс только тогда, когда он был изменен с момента последних обновлений кеша этого документа.

В каких случаях может применяться этот код? Если ответ сервера сообщает вам, что параметры документа If-Modified-Since или If-Match не изменились со времени генерирования последнего кеша. Тогда нет нужды повторно отправлять ресурс на проверку.

305 Use Proxy (Использовать прокси)
305 код дает понять пользователю, что доступ к запрашиваемому ресурсу осуществим только через прокси-сервер, указанный в ответе.
Когда он показывается? Он часто отображается в связи с мерами безопасности и обеспечивает доступ к запрашиваемым URL-адресам.

306 Switch Proxy (Переключить прокси)
Изначально он означал, что «последующие запросы должны использовать указанный прокси», но в настоящее время не используется.

307 Temporary Redirect (Временный редирект)
Такой код отображается, если открываемый ресурс временно используется для другого URL-адреса, который также содержится в ответе. 307 немного отличается от 302 кода – он является его более конкретной версией.

Когда он используется? Он выводится почти в аналогичных ситуациях, что и при 302, но пользователь должен продолжать запрашивать исходный URL-адрес при следующих запросах или до того времени, пока не будет выведен другой статус сервера.

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

Класс ответов 4xx указывает на ошибки на стороне клиента или тот факт, что местоположение никогда (или уже) не существовало.

400 Bad Request (Плохой запрос)
Запрос не обрабатывается правильно в связи с синтаксической ошибкой.
Для чего предназначен этот код? Если пользователь делает запрос на информацию, но при этом пренебрегает протокольными правилами передачи гипертекста. Запрос не следует делать повторно без надлежащих перемен в синтаксисе.

401 Unauthorized (Неавторизирован)
Он имеет отношение к запросу ресурса, который нуждается в авторизации. Код 401 информирует, что предварительную авторизацию отклонили, поскольку переданные пользовательские данные были неверные.

Когда он отображается? В случаях, если пользователь делает запрос и использует при этом некорректные входные данные для авторизации (среди них, логин и пароль).

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

Какова сфера применения этого кода? Старый сервис Apple MobileMe сообщал об 402-ошибке, если аккаунт пользователя в MobileMe подозревался в любой форме злоупотреблений его ресурсами. Также видеохостинг Youtube использует этот статус, если некий IP-адрес использует чрезмерно большое количество запросов. Поэтому пользователю приходится ввести CAPTCHA.

403 Forbidden (Запрещен)
Пользователь пробует добиться доступа к веб-ресурсу, на который у него нет прав, а авторизация здесь никак не может помочь.
Что насчет применения этого кода? Он используется, когда сервер может понять запрос, но не разрешает выполнить его, поскольку у клиента имеются ограничения доступа к текущему разделу. Обычно такое наблюдается, если веб-ресурс не предназначен для открытого доступа.

404 Not Found (Не найден)
Большинство пользователей знакомо с 404 ошибкой. Она указывает на то, что искомый ресурс невозможно найти, но в будущем – когда он может появиться там – к нему можно получить доступ. Также здесь разрешаются все следующие обращения от клиента. Но в большом количестве таких случаев используется код редиректа класса 3xx, и пользователь перенаправляется на альтернативный ресурс или местоположение.
Когда демонстрируется этот код? Довольно часто, особенно если страницу удалили или переместили. Часто в таких случаях сервер в автоматическом режиме генерирует доступную страницу с ошибкой 404.

405 Method Not Allowed (Метод не разрешен)
Метод, посредством которого осуществляется запрос к ресурсу, является недоступным. Иными словами, появляется ошибка при попытке использовать функцию в формате GET, тогда как требуется ввод данных через метод POST (либо с помощью метода PUT с веб-документами только для чтения).

Когда появляется такой статус-код? Ошибки 405 выходят через их отношение со специфическими объектами страницы, для которых и выполнялось обращение к серверу. К примеру, если часть запроса скрипта имеет отличия с запросом пользователя, подразумевавшего применение этого скрипта.

406 Not Acceptable (Недопустимо)
Запрашиваемый ресурс имеет возможность генерировать только тот контент, который не может использоваться в Accept-хедерах самого запроса. Браузер может обеспечить сервер характеристиками данных, которые будут приниматься из сервера.

В каких случаях такой код может быть использован? В ситуациях, когда форма файла ресурса, который запрашивается не подходит под формат, доступный для распознавания пользователем. Речь здесь идет прежде всего о языке программирования, а не о английском!

407 Proxy Authentication Required (Нужна авторизация прокси)
Как и статус-код 401, значение 407 обозначает, что клиенту следует предварительно авторизоваться через прокси-сервер. Для выполнения этого действия и осуществления процесса авторизации, прокси-сервер должен вернуть поле с заголовком Proxy-authenticate, которое отвечает стандартам, предъявляемым сервером.
Когда появляется этот статус-код? В случаях, если сервер «убежден», что запрос данных от клиента является правильным, но получить доступ к веб-ресурсу возможно лишь через авторизацию с помощью прокси-сервера.

408 Request Timeout (Тайм-аут запроса)
Истекло время ожидания сервером ретрансляции от клиента.
Когда такой статус-код применяться? Используя спецификацию W3 HTTP: «Со стороны клиента не поступало запроса в выделенном временном интервале, когда его ждал сервер. Клиент имеет возможность повторить запрос в любое время».

409 Conflict (Конфликт)
Код 409 является индикатором ситуации, когда запрос не выполняется в связи с противоречивостью обращения к веб-документу.
Когда он применятся? Пользователь может получить такой код в случае загрузке файла на веб-сервер, где расположена более поздняя версия этого файла, что приводит к конфликту между версиями в системе управления.

410 Gone (Исчез)
Сервер дает подобный ответ, если раньше ресурс находился по определенному URL-адресу, но его удалили и на данный момент он недоступен. Пользователю не следует несколько раз повторять одно и то же самое обращение.

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

411 Length Required (Требуется длина)
Запрос не указывает длину контента, и запрашивался в совершенной форме.
Когда этот код показывается? Когда браузер не определяет длину запрашиваемого содержимого в заголовке запроса. Сервер не будет принимать запрос без валидного поля заголовка контента.

412 Precondition Failed (Сбой предварительного условия)
Сервер не отвечает на одно из предварительных условий, которые отправитель указал в запросе. Иными словами, один или несколько заголовков запросов были возвращены с атрибутом false.

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

413 Request Entity Too Large (Объект запроса слишком большой)
Код 413 отображается в случаях, когда сервер отказывается обрабатывать запрос, потому что тело запроса слишком велико.
Когда этот код может применяться? При использовании метода POST с контентом, который больше по объему, чем сервер, способен обработать.

414 Request-URL Too Long (URL запроса слишком длинный)
Этот код отображается, когда сервер не может обработать запрос, потому что указанный URL слишком длинный.
Когда этот код может применяться? Когда POST-запрос преобразуется в GET-запрос. POST-запрос поддерживает отправку неограниченного количества данных, объединяя их при обращении к серверу. Однако, если запрос должен быть преобразован в GET-формат, он позволит привязать данные формы к URL-адресу, что даст возможность хранить информацию в больших размерах, чем она была доступна.

415 Unsupported Media-Type (Неподдерживаемый тип)
Код 415 отправляется, для указания, что сервер заметил часть запроса, которая была сделана в неподдерживаемом формате.
Когда отображается такой код? Когда в запросе не указываются какие-либо типы носителей, поддерживаемые ресурсом или сервером. Например, пользователь запрашивает изображение в расширении, которое не поддерживается веб-сервером. Сервер знает, что запрашивалось, но не понимает формат, в котором хотели получить ресурс.

416 Requested Range Not Satisfiable (Диапазон не подходит)
Этот ответ пользователь получает, когда он запрашивает часть ресурса, но в то же время этот фрагмент не может быть предоставлен.
Когда такой статус может применяться? Когда сервер запрашивает байты XXX-YYY ресурса, но ресурс немного меньше, чем указано при обращении.

417 Expectation Failed (Ошибка ожидания)
Такой статусный ответ получают, когда по какой-то причине сервер не удовлетворяет значение поля Expect заголовка запроса.
Когда этот код может применяться? Все абсолютно прозрачно. Когда один из заголовков запросов, заголовок «Expect», получает обращение, на которое сервер не в состоянии ответить.

418 I’m a teapot (Я чайник)
Этот код был создан в 1998 году как одна из традиционных шуток на первое апреля IETF, в RFC 2324, как Hyper Text Coffee Pot Control Protocol и вряд ли он когда-нибудь будет обрабатываться современными HTTP-серверами.

Может ли он использоваться? Конечно нет, все это было -15 лет назад и делалось ради смеха.

422 Unprocessable Entity (Необрабатываемый объект)
Сервер принял запрос и понял его суть, но не может выполнить обращение из-за содержания в нем некоторых семантических ошибок.
Когда используется этот статус-код? Когда на стороне сервера прошло успешное принятие обращения, и сервер способен работать с указанным форматом данных; в теле запроса XML-документ содержит правильные синтаксические конструкции, но также в нем содержится какая-либо логическая ошибка, в связи с которой не представляется возможным управлять ресурсом.

423 Locked (Заблокирован)
Целевой ресурс, указанный в запросе, блокируется в связи с применением к нему определенного метода. Чтобы сделать ресурс доступным, следует разблокировать его или предоставить корректные данные авторизации.
Когда этот код может применяться? Когда ресурс является закрытым, в основном это делается в целях обеспечения безопасности.

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

425 Unordered Collection (Неупорядоченная коллекция)
Код 425 показывается пользователю, когда ресурс определяется одним из черновиков расширенного протокола коллекций WebDAV (Advanced Collections Protocol), но отсутствует в Advanced Collections Protocol и Versioning Ordered Collections Protocol.

426 Upgrade Required (Нужно обновление)
Этот код показывается, когда сервер дает клиенту инструкции по обновлению протокола (переключения на другой или новый протокол) Когда используется код? Обычно, когда в браузере используются устаревшие протоколы.

428 Precondition Required (Требуется предпосылка)
Исходный сервер требует указать предварительные условия при обращении. Этот код разработан во избежание конфликтных версий ресурса в тех ситуациях, когда клиент получает (GET) состояние ресурса, изменяет и отправляет (PUT) его обратно на сервер, и в то же время какая-то третья сторона также изменяет местоположение прямо на севере, что приводит к конфликту.

Когда этот код может применяться? По запросу индикации условий, сервер как бы дает гарантии клиентам, что они используют правильную текущую копию ресурса. Если это не совсем так, то пользователь получает ошибку 428.

429 Too Many Requests (Слишком много запросов)
Этот ответ отправляется, если со стороны клиента поступало слишком большое количество обращений за короткий промежуток времени.
Когда используется этот код? Когда пользователь отправляет слишком много обращений за краткосрочный период.

431 Request Header Fields Too Large (Поля заголовков слишком большие)
Появляется, когда сервер не намерен совершать обработку запроса, поскольку какое-нибудь из полей заголовка (или все существующие поля) слишком велики.
Когда он применяется? Базово, когда заголовок запроса, поступающий от юзера больше, чем способен обработать сервер. Обращение можно повторить после того, как поля заголовка в нем будут сокращены.

444 No Response (Нет ответа)
Используется в лог-файлах сервера Nginx, для указания, что сервер не передавал информацию обратно пользователю и закрыл соединение.
Какова сфера применения кода? В основном он использовался как инструмент защиты от вредоносного софта.

449 Retry With (Microsoft) (Повторить попытку)
Расширение Microsoft, которое указывает, что запрос следует повторить после завершения соответствующего действия.
Когда этот код может применяться? Он часто создается, когда настройки запроса не соответствуют тому, что способен проверить сервер.

450 Blocked by Windows Parental Controls – Microsoft (Заблокировано родительским контролем Windows)
Расширение Microsoft. Эта ошибка возникает, когда в параметрах родительского контроля Windows установлена блокировка доступа к некоторым веб-документам.
Когда применяется 450 код? В случае, если родители (зная об этой функции) прибегают к использованию родительского контроля, а id-access запросил доступ к заблокированному ресурсу.

451 Unavailable For Legal Reasons (Недоступен по юридическим причинам)
Новый HTTP-код статуса для ресурсов, которые заблокированы по юридическим соображениям. Применяется, чтобы указать, что доступ к нужному веб-ресурсу заблокировали по юридическим мотивам: например, посредством цензуры или правительства.

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

Коды 5xx выделены для случаев неудачной работы на стороне сервера.
Эти ответы сервера часто отображаются, когда запросы пользователя не могут быть обработаны сервером по той или иной причине. Сервер должен иметь специальное сообщение для браузера, которое должно отображаться пользователю – оно уведомляет, что сервер (по какому-либо поводу) не в состоянии произвести обработку запроса.

500 Internal Server Error (Внутренняя ошибка сервера)
Этот статус сообщает о внутренней ошибке сервера, которая не совпадает с другими ошибками того же класса.
Этот код используется, если ресурс или ссылка создается на сервере (например, календарь в системе резервирования), который технически не существует как ссылка или доступный ресурс, но пользователь видите их как ссылки.

501 Not Implemented (Не поддерживается)
Сервер либо не понимает метод запроса, либо не поддерживает инструкции, нужные, чтобы обработать обращение.
Вы можете столкнуться с указанным кодом 501, когда сервер не имеет поддержки стандартных протоколов запросов, среди которых GET, OPTIONS, HEAD, POST и т. д.

502 Bad Gateway (Плохой шлюз)
Пользователь увидит 502 код, если сервер, работает в качестве шлюза или прокси-сервера, и он получил недопустимый ответ от сервера верхнего уровня.
Когда используется подобный код? Обычно, когда сервер высшего уровня и прокси / шлюз не согласованы с протоколами, которые представленными в обращении. Как результат появляется ошибка обмена данных.

503 Server Unavailable (Сервер недоступен)
Код 503 означает, что возникли технические причины, из-за которых сервер на определенное время не способен обработать набор данных.
Его допустимо использовать в случаях, когда на сайт есть повышенный спрос, но у сервера нет возможности обрабатывать все входящие запросы.

504 Gateway Timeout (Тайм-аут шлюза)
Сервер как шлюз или прокси-сервер не дождался ответа от вышестоящего сервера, чтобы завершить текущий запрос.
Когда этот код может применяться? Когда прокси или шлюз используют как канал передачи данных, а два сервера при этом ожидают на ответ.

505 HTTP Version Not Supported (Версия HTTP не поддерживается)
Сервер не поддерживает версию HTTP протокола, обозначенную при обращении к нему.
Где используется такой код? В тех случаях, которые были указаны выше! Если HTTP протокол более старый, чем нужно серверу, и, как следствие, он не поддерживается.

506 Variant Also Negotiates (Вариант также перенаправляется)
Такой ответ сервера последует, если при оформлении ошибочной конфигурации выбранный параметр указывает сам на себя, что приводит к прерыванию процесса связи.
Когда он применяется? Когда сервер настроен неправильно и не может обработать запрос.

507 Insufficient Storage (Недостаточно места)
Ошибка 507 имеет место, когда сервер не может разместить данные, поскольку для текущего запроса недостаточно пространства.
Этот код может быть применен, когда сервер загружен в полном объеме, а пользователь запрашивает ресурс, который уже имеется в наличии. Трудность здесь заключается в том, что на сервере нет места для хранения отправленных в запросе данных, чтобы отправить запрашиваемый ресурс.

509 Bandwidth Limit Exceeded (Превышена пропускная способность)
Этот код ответа используется, когда веб-сайт лимитирует ограничение трафика, предназначенное для него.
Когда используется этот статус? Когда Apache запускает правильное расширение, а ISP имеет пропускную способность, которая может быть скоро превышена. Здесь имеется несколько форм ограничения.

510 Not Extended (Нет расширения)
Код 510 появляется, когда на сервере нет расширения, которое хочет использовать клиент. Когда этот код появляется? Когда сервер требует больше данных в запросе.

511 Network Authentication Required (Требуется аутентификация сети)
Этот статус-код демонстрируется, если клиенту следует сначала авторизоваться в сети, к примеру, необходимо ввести пароль для платного доступа в сеть Интернет.
Когда используется этот код? Когда пользователь сначала должен дать свое согласие на условия использования, прежде чем он получит доступ к Интернету (например, к Wi-Fi точке доступа).

Ирина Крутко

SEO специалист

Ирина — SEO-эксперт Sitechecker. Она отвечает за категорию и обзоры веб-хостингов. Одержима исследованиями, разработкой и созданием ценного контента.

Facebook Linkedin

Список 55 ошибок HTTP с расшифровкой

Расшифровка 55 состояний прикладного протокола HTTP (протокол передачи гипертекста): от информационных сообщений до ошибок.

Во время запроса информации с удаленного веб-сервера может возникнуть ошибка. Тогда веб-сервер посылает в ответ код ошибки HTTP. Например 404 — Not Found (ресурс не найден).

Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

  1. Информационные (100-105).
  2. Успешные (200-226).
  3. Перенаправление (300-307).
  4. Ошибка клиента (400-499).
  5. Ошибка сервера (500-510).

Чтобы получить сведения об ошибке, введите её код в поле поиска по странице. Для этого нажмите сочетание клавиш CTRL + F и укажите номер.

Содержание

100

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

101

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

102

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

200

ОК
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201

Created
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется[источник не указан 336 дней] ещё указывать в заголовке характеристики созданного ресурса (например, в поле 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.

226

IM Used
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

300

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

301

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

302

Found, 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).

400

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

401

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

402

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

403

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

404

Not Found
Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 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
Возвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

413

Request Entity Too Large
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414

Request-URL Too Long
Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415

Unsupported Media Type
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416

Requested Range Not Satisfiabl
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

417

Expectation Failed
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

422

Unprocessable Entity
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423

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

424

Failed Dependency
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425

Unordered Collection —
Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol[14].

426

Upgrade Required
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено вRFC 2817 для возможности перехода к TLS посредством HTTP.

449

Retry With
Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

456

Unrecoverable Error
Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

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

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

Сперва определимся с терминами.

  • Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
  • Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

  • 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
  • 4** – сбой на стороне юзера.
  • 3** – обнаружен редирект на другой адрес (не ошибка).
  • 2** – запрос обработан успешно (не ошибка).
  • 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Какие проверки сайта нужно делать ежемесячно: профилактика и диагностика ошибок

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

203 – данные получены не из первоисточника (возвращаемые данные идут не от исходного сервера, а от какого-то другого) и могут быть устаревшими.

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

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

206 – ошибка частичного содержимого. Если клиент хочет выполнить загрузку данных в несколько потоков, а сервер выполняет только часть GET-запроса, будет возникать 206-ая ошибка.

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

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

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Топ-64 фактора ранжирования в Google, актуальных в 2021 году

Трехсотые – запросы на редирект

300 – не удалось идентифицировать точный URL. Такой ответ возникает, когда существует множественный выбор, и краулер не знает, к какой именно странице относится ресурс.

301 – документ был навсегда перемещен на новый URL. Так должны отвечать все веб-страницы, которые удалены или являются зеркалами, дублями. Со временем все указанные страницы будут склеены с целевой веб-страницей (присоединены к ней) автоматически. Если возникает такая ошибка, нужно настроить 301-ое перенаправление с устаревшего URL на актуальный (если речь идет о веб-странице, которая уже ранжировалась, но ее URL изменился). В таком случае все позитивные метрики, включая вес URL, будут сохранены.

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

303 – нужно направить пользователя на иной URL. 303-ый код можно получить исключительно GET-запросом. В идеале, этот код нужно отдавать, когда требуется редиректнуть посетителя на близкорелевантую, но не идентичную странице.

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

307 – документ был временно перемещен на иной URL. Идеальный вариант, если требуется временно редиректнуть посетителя, но оставить техническую возможность отправки POST-запросов.

Четырехсотые – сбои на стороне клиента

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

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

Страница 404: самые креативные, смешные и лаконичные варианты

405 – некорректный метод (указывается в запросной строке клиента) для выбранного документа. Метод запроса определяет точное действие, которое должно быть выполнено для указанного ресурса.

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

410 – ресурс более не существует по указанному URL. Если страница удаляется целенаправленно, лучше делать так, чтобы она отдавала именно 410-ый. Краулер обойдет такую страницу, получит этот код и больше никогда на нее не вернется, так как поймет, что она удалена навсегда. Если речь о веб-странице, которая была удалена временно, гораздо эффективнее использовать 404-ый ответ. Если страница удалена намерено и навсегда, но в SERP имела хорошие места и приносила трафик, лучше сделать редирект на максимально релевантную существующую страницу.

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

416 – некорректное значение Range (диапазон). Ответ возникает в случаях, когда в самом HTTP-заголовке прописывается некорректный байтовый диапазон. 416-ый отдается в случаях, когда сервер не может взаимодействовать с запрашиваемыми диапазонами. Причина – отсутствие диапазона в необходимом документе или опечатка в синтаксисе.Сервер просто не имеет возможности работать с запрашиваемыми диапазонами. Проверьте синтаксис значения Range – он должен обязательно соблюдаться. Скорее всего, документ просто не имеет запрашиваемых диапазонов. Обновите страницу.

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

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

423 – используемый ресурс был заблокирован для выбранного HTTPметода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

429 – слишком много запросов. Ошибка отдается, когда один пользователь проявляет чрезмерно большую активность за короткий временной интервал. Проверьте плагины используемой CMS. В идеале, отключите их все и включайте по очереди, пока не доберетесь до источника проблемы.

451 – доступ к серверу заблокирован по решению судебных органов. Можно плодить бесконечные дубли или вообще создать новый домен, но рано или поздно страницу с идентичным содержимым все равно заблокируют. Временное решениеразместить проблемное содержимое на другом домене. Провайдеры могут подстраховаться и блокировать не только отдельные страницы, но и сайты целиком. Не нарушать закон – единственное, что можно посоветовать в этом случае.

Пятисотые – серверные сбои

500 – серверу не удается полностью обработать запрос. Такой код отдается, когда существует непредвиденное условие, мешающее выполнению запроса. Чаще всего внутренняя ошибка сервера может появляться при серверных сбоях. Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess), нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

Как файл htaccess может улучшить ваш сайт: топ-10 лайфхаков для начинающего вебмастера

Проверяйте конфликты плагинов и дополнений. Нередко 500-ая возникает, когда в настройках административной панели хостинга указана одна версия PHP, а на самом сайте используется другая. Последнее также создает высокую статическую нагрузку на хостинг. Если вам было бы узнать о пятисотой подробнее, пишите в комментариях, и я напишу развернутый материал на эту тему.

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

502 – шлюзовый сбой. Возникает при получении некорректного ответа от сервера, находящегося по иерархии выше. Актуально исключительно для прокси и шлюзовых конфигураций.

503 – данный ответ возникает в случаях, когда существуют технические неполадки, не позволяющие интерпретировать введенный запрос. Скорее всего, ваш сервер просто на обслуживании или сильно перегружен. Уменьшите число перманентных запросов к базам данных. Убедитесь, что на сервере нет профилактических или других работ, ограничивающих его пропускную способность. Не используйте VPN.

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config. php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

  • mainspy;
  • 2ip;
  • cy-pr;
  • wwhois;
  • 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

21 полезный плагин Google Chrome для SEO-специалиста

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

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

кодов состояния ответа HTTP | mlytics

Коды состояния ответа HTTP (или просто коды состояния) — это трехзначные коды, выдаваемые сервером в ответ на запрос клиента со стороны браузера. Эти коды состояния служат средством быстрого и краткого сообщения о том, как сервер работал и отвечал на запрос клиента. Эти коды также включают коды из запроса комментариев IETF (RFC), другие спецификации и некоторые дополнительные коды, используемые в общих приложениях HTTP.

Администрация адресного пространства Интернета (IANA) ведет официальный реестр кодов состояния HTTP. Из 3 цифр кода состояния HTTP первая цифра определяет категорию кода состояния, а последние две цифры назначаются для определенного типа ответа в данной категории. Существует пять различных категорий кодов состояния HTTP, и они классифицируются в зависимости от типа ответа, который сервер передает клиенту:

  • 1XX — информационный код 9.0009 : Эта категория указывает, что запрос был получен и понят. Он выдается на временной основе, пока продолжается обработка запроса. Он предупреждает клиента о необходимости дождаться окончательного ответа. Сообщение состоит только из строки состояния и необязательных полей заголовка и заканчивается пустой строкой.
  • 2XX — Код успеха : Эта категория указывает, что действие, запрошенное клиентом, было получено, понято и принято. По сути, это означает, что запрос, сделанный клиентом, был хорошим запросом, и что сервер полностью и успешно выполнил то, что должен был сделать.
  • 3XX — код перенаправления : эта категория указывает, что клиент может предпринять дополнительные действия для выполнения запроса. Обычно это дополнительное действие заключается в перенаправлении пользователя на другой URL-адрес. Многие из кодов состояния в этой категории используются при перенаправлении URL-адресов.
  • 4XX — код ошибки клиента : эта категория указывает, что запрос не может быть выполнен из-за ошибки, исходящей от клиента. Запрос может содержать неправильный синтаксис или отсутствие авторизации и т. д. Сервер должен включать сущность, содержащую объяснение ситуации с ошибкой (кроме случаев ответа на запрос HEAD), а также является ли это временным или постоянным состоянием.
  • 5XX — код ошибки сервера : эта категория указывает, что сервер обнаружил ошибку или не может выполнить действительный запрос. Сервер должен включать сущность, содержащую объяснение ситуации с ошибкой (за исключением случаев ответа на запрос HEAD), и указывать, является ли это временным или постоянным состоянием.

Ниже перечислены наиболее распространенные коды состояния ответов HTTP для каждой категории.

А. Информационные коды

100 Продолжить

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

Используется для информирования клиента о том, что начальная часть запроса получена и еще не отклонена сервером. Затем браузер должен продолжить отправку оставшейся части запроса или проигнорировать этот ответ, если запрос уже был выполнен. Сервер должен отправить окончательный ответ после завершения запроса. Браузер должен сначала включить Expect: 100-continue в заголовок запроса в своем первоначальном запросе, чтобы получить код состояния 100 Continue в ответ перед отправкой тела.

101 Переключение протоколов

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

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

103 Ранние подсказки

Этот код состояния используется вместе с заголовком Link, чтобы позволить пользовательскому агенту (например, браузеру) начать предварительную загрузку ресурсов, пока сервер все еще готовит ответ.

B. Коды успешного выполнения

200 OK

Этот код состояния указывает на успешное выполнение запроса. Значение успеха зависит от метода HTTP-запроса:

  • GET: запрошенный ресурс был передан в ответе вместе с телом сообщения.
  • HEAD: Заголовки представления передаются в ответе без тела сообщения.
  • POST: ресурс, описывающий результат действия, передается в ответе.
  • TRACE: ответ содержит сообщение запроса, полученное сервером.

Код состояния для успешного результата PUT или DELETE часто представляет собой не 200 OK, а 204 No Content или 201 Created, если ресурс загружается впервые. Ответ 200 кэшируется по умолчанию.

201 Created

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

202 Принят

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

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

203 Неавторизованная информация

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

204 No Content

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

Этот ответ предназначен для того, чтобы разрешить ввод для выполнения действий, не вызывая изменения активной страницы браузера, хотя любая новая или обновленная метаинформация будет применяться к активной странице браузера. Например, при реализации функции «сохранить и продолжить редактирование» для вики-сайта. В этом случае для сохранения страницы будет использоваться запрос PUT, а ответ 204 будет отправлен, чтобы указать, что редактор не должен быть заменен другой страницей. Ответ 204 по умолчанию кэшируется (в такой ответ включается заголовок ETag).

C. Коды перенаправления

300 Множественный выбор

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

В зависимости от формата и возможностей браузера выбор наиболее подходящего варианта может выполняться автоматически. Если у сервера есть предпочтительный выбор представления, он будет включать конкретный URI для этого представления в поле «Расположение», и браузер может использовать значение поля «Расположение» для автоматического перенаправления. Поскольку не существует стандартизированного способа выбора одного из ответов, этот код ответа используется очень редко. Ответ 300 кэшируется по умолчанию.

301 Перемещено навсегда

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

Рекомендуется использовать код состояния 301 только в качестве ответа для методов GET или HEAD, поскольку изменение метода явно запрещено с этим статусом, и вместо этого использовать 308 Permanent Redirect для методов POST. Ответ 301 кэшируется по умолчанию.

302 Найдено

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

Рекомендуется использовать код 302 только в качестве ответа на методы GET или HEAD, так как изменение метода явно запрещено для этого статуса, и использовать 307 Temporary Redirect, если метод изменяется при выполнении перенаправленного запроса. В тех случаях, когда вы хотите, чтобы используемый метод был изменен на GET, вместо этого используйте 303 See Other. Это также полезно, когда вы хотите дать ответ на метод PUT, который не является загруженным ресурсом, а подтверждающим сообщением, например: «вы успешно загрузили XYZ». Ответ 302 можно кэшировать, если это указано в поле заголовка Cache-Control или Expires.

303 См. Другое

Этот код состояния указывает, что перенаправления ссылаются не на недавно загруженные ресурсы, а на пользовательскую страницу (например, страницу подтверждения или страницу прогресса загрузки). Этот код состояния обычно отправляется обратно в результате PUT или POST. Метод, используемый для отображения этой перенаправленной страницы, всегда GET.

304 Не изменено

Этот код состояния указывает, что нет необходимости повторно передавать запрошенные ресурсы. Это неявное перенаправление на кешированный ресурс. Это происходит, когда метод запроса безопасен, например. GET или HEAD, или когда запрос является условным и использует заголовок If-None-Match или If-Modified-Since. Эквивалентный ответ 200 OK включал бы заголовки Cache-Control, Content-Location, Date, ETag, Expires и Vary.

307 Временное перенаправление

Этот код состояния указывает, что запрошенный ресурс был временно перемещен в URI. Временный URI задается полем Location в ответе. Единственная разница между 307 и 302 Found заключается в том, что 307 гарантирует, что метод и тело не будут изменены при выполнении перенаправленного запроса. Для запросов GET поведение 302 и 307 идентично. Поведение с не-GET-методами и 302 Found становится непредсказуемым в Интернете, тогда как поведение с 307 предсказуемо.

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

308 Постоянное перенаправление

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

D. Коды ошибок клиента

400 Неверный запрос

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

401 Неавторизованный

Этот код состояния указывает, что запрос не был применен, так как отсутствуют действительные учетные данные для проверки подлинности для целевого ресурса. Этот статус отправляется с заголовком WWW-Authenticate, который содержит информацию о том, как правильно авторизоваться. С этим кодом состояния можно повторить запрос, включив аутентификацию для доступа к целевому ресурсу. Этот статус аналогичен 403, но в этом случае возможна аутентификация.

402 Требуется оплата

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

403 Запрещено

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

Этот статус аналогичен 401 Unauthorized, но в этом случае повторная аутентификация не имеет значения, поэтому повторять запрос не нужно. Доступ постоянно запрещен и привязан к логике приложения, например, недостаточные права на ресурс. Для любых методов запроса, кроме HEAD, если сервер хочет, чтобы причина отказа была доступна клиенту, то можно использовать 403. Однако, если сервер не хочет предоставлять эту информацию, вместо этого можно использовать 404 Not Found.

404 Не найдено

Этот код состояния указывает, что сервер не может найти ничего, соответствующего Request-URI. Ссылки, которые ведут на страницу 404, часто называют неработающими или мертвыми ссылками, и они могут быть подвержены гниению ссылок. Нет никаких указаний на то, является ли состояние временным или постоянным. Но если сервер знает, что ресурс удален безвозвратно, то вместо статуса 404 следует использовать 410 Gone. Этот код состояния также обычно используется, когда сервер не желает точно раскрывать, почему запрос был отклонен, или когда никакой другой ответ не применим. Ответ 404 кэшируется по умолчанию.

405 Метод не разрешен

Этот код состояния указывает, что метод запроса известен серверу, но не поддерживается целевым ресурсом. Метод, указанный в строке запроса, не разрешен для ресурса, указанного в Request-URI. Сервер ДОЛЖЕН генерировать поле заголовка Allow, содержащее список поддерживаемых методов для запрошенного ресурса. Ответ 405 кэшируется по умолчанию.

408 Истечение времени ожидания запроса

Этот код состояния указывает, что сервер хотел бы закрыть это неиспользуемое соединение, так как запрос превысил время, которое сервер был готов ждать. Клиент МОЖЕТ повторить запрос без изменений в любое время. Сервер должен отправить поле заголовка Connection «закрыть» в ответе, поскольку 408 означает, что сервер решил закрыть соединение, а не продолжать ждать.

409 Конфликт

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

Скорее всего, это происходит в ответ на запрос PUT. Например, вы можете получить 409ответ при загрузке файла, который старше, чем тот, который уже находится на сервере, что приводит к конфликту контроля версий. В этом случае ответ должен содержать список различий между двумя версиями в формате, определяемом Content-Type ответа.

410 Исчез

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

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

414 Слишком длинный URI

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

Есть несколько условий, когда это может произойти: а) когда клиент неправильно преобразовал запрос POST в запрос GET с длинной информацией о запросе, б) когда клиент попал в цикл перенаправления (например, перенаправленный префикс URI, который указывает на суффикс самого себя), или c) когда сервер подвергается атаке со стороны клиента, пытающегося использовать потенциальные бреши в безопасности. Ответ 414 кэшируется по умолчанию.

415 Неподдерживаемый тип носителя

Этот код состояния указывает, что сервер отказывается принять запрос, поскольку формат полезной нагрузки не поддерживается. Проблема с форматом может быть связана с указанным в запросе Content-Type или Content-Encoding или в результате непосредственной проверки данных.

418 Я чайник

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

429 Слишком много запросов

Этот код состояния указывает, что пользователь отправил слишком много запросов за заданный период времени («ограничение скорости»). Представления ответа могут включать подробности, объясняющие условие, и заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос. Однако, когда сервер подвергается атаке или просто получает очень большое количество запросов от одной стороны, ответ на каждый с кодом состояния 429 будет потреблять ресурсы, следовательно, когда может быть более подходящим просто сбросить соединения или предпринять другие шаги. .

E. Коды ошибок сервера

500 Внутренняя ошибка сервера

Этот код состояния указывает, что сервер столкнулся с непредвиденной ситуацией, которая помешала ему выполнить запрос. Этот ответ об ошибке обычно используется как общий «всеохватный» ответ, указывающий, что сервер не может найти лучший код состояния 5xx для ответа. Иногда администраторы серверов регистрируют ответы об ошибках, такие как код состояния 500, с более подробной информацией о запросе, чтобы предотвратить повторение ошибки в будущем.

501 Не реализовано

Этот код состояния означает, что сервер не поддерживает функции, необходимые для выполнения запроса. Этот статус также может отправлять заголовок Retry-After, сообщающий клиенту, когда следует проверить, поддерживается ли функциональность к тому времени. Код 501 — это то, что вы не можете исправить, но требует исправления веб-сервером, к которому вы пытаетесь получить доступ.

Это правильный ответ, когда сервер не распознает метод запроса и не может поддерживать его для любого ресурса. Единственными методами, которые должны поддерживать серверы, являются GET и HEAD, поэтому они не должны возвращать 501. Если сервер распознает метод, но намеренно не поддерживает его, соответствующий ответ — 405 Method Not Allowed. Ответ 501 кэшируется по умолчанию, если заголовки кэширования не указывают иное.

502 Bad Gateway

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

503 Служба недоступна

Этот код состояния указывает, что сервер в настоящее время недоступен и не готов обрабатывать какие-либо запросы из-за временной перегрузки или технического обслуживания сервера. Эта реакция используется как временная мера, которая, как ожидается, будет смягчена через некоторое время. Вместе с этим ответом заголовок Retry-After должен содержать предполагаемое время восстановления службы, а также должна быть включена удобная страница с объяснением проблемы. Если Retry-After не указан, клиент ДОЛЖЕН обрабатывать ответ так же, как и ответ с кодом 500 Internal Server Error.

504 Время ожидания шлюза

Этот код состояния указывает, что сервер, действуя как шлюз или прокси, не получил своевременный ответ от вышестоящего сервера, указанного URI (например, HTTP, FTP, LDAP) или каким-либо другим вспомогательный сервер (например, DNS) при попытке выполнить запрос. Код 504 обычно нельзя исправить, но требуется исправление веб-сервером или прокси-серверами, через которые вы пытаетесь получить доступ.

Коды состояния HTTP — REST API Tutorial

REST API используют часть Status-Line ответного сообщения HTTP для информирования клиентов об общем результате их запроса. RFC 2616 определяет синтаксис строки состояния, как показано ниже:

Строка состояния = HTTP-версия SP Код состояния SP Reason-Phrase CRLF

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

  • 1xx: информационный — Передает информацию на уровне протокола передачи.
  • 2xx: Успех — Указывает, что запрос клиента был успешно принят.
  • 3xx: перенаправление — указывает, что клиент должен предпринять дополнительные действия для выполнения своего запроса.
  • 4xx: Ошибка клиента — эта категория кодов состояния ошибки указывает на клиентов.
  • 5xx: ошибка сервера — сервер берет на себя ответственность за эти коды состояния ошибки.

1xx Коды состояния [Информация]

16

Код состояния

Описание

100. Продолжайте 99329

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

101 Протокол переключения

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

102 Обработка (WebDAV)

Указывает, что сервер получил и обрабатывает запрос, но ответа пока нет.

103 Ранние подсказки

В первую очередь предназначен для использования с заголовком Link . Он предлагает агенту пользователя начать предварительную загрузку ресурсов, пока сервер готовит окончательный ответ.

2xx Status Codes [Success]

Status Code

Description

200 OK

Indicates that the request has succeeded.

201 Created

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

202 Принят

Указывает, что запрос получен, но еще не выполнен. Обычно он используется в запросах на ведение журнала и пакетной обработке.

203 Неофициальная информация

Указывает, что возвращенная метаинформация в заголовке объекта не является окончательным набором, доступным на исходном сервере, а получена из локальной или сторонней копии. Представленный набор МОЖЕТ быть подмножеством или надмножеством исходной версии.

204 Нет содержимого

Сервер выполнил запрос, но не должен возвращать тело ответа. Сервер может вернуть обновленную метаинформацию.

205 Сбросить содержимое

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

206 Partial Content

Используется, когда заголовок Range отправляется от клиента для запроса только части ресурса.

207 Мультистатус (WebDAV)

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

208 Уже сообщено (WebDAV)

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

226 Используемый мгновенный обмен сообщениями

Сервер выполнил запрос GET для ресурса, и ответ представляет собой представление результата одной или нескольких манипуляций с экземпляром, примененных к текущему экземпляру.

3xx Status Codes [Redirection]

Status Code

Description

300 Multiple Choices

The request has more than one possible response. Пользовательский агент или пользователь должен выбрать один из них.

301 Перемещено навсегда

URL запрошенного ресурса был изменен навсегда. Новый URL задается Поле заголовка Location в ответе. Этот ответ можно кэшировать, если не указано иное.

302 Найдено

URL запрошенного ресурса был временно изменен. Новый URL-адрес задается полем Location в ответе. Этот ответ можно кэшировать только в том случае, если он указан в поле заголовка Cache-Control или Expires .

303 См. Другое

Ответ можно найти по другому URI, и его СЛЕДУЕТ извлекать с помощью метода GET для этого ресурса.

304 Не изменено

Указывает клиенту, что ответ не был изменен, поэтому клиент может продолжать использовать ту же кэшированную версию ответа.

305 Использовать прокси (устарело)

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

306 (не используется)

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

307 Временное перенаправление

Указывает, что клиент должен получить запрошенный ресурс по другому URI тем же методом, который использовался в предыдущем запросе. Он аналогичен 302 Found за одним исключением: будет использоваться тот же метод HTTP, что и в предыдущем запросе.

308 Постоянное перенаправление (экспериментальное)

Указывает, что ресурс теперь постоянно находится в другом URI, указанном в заголовке Location . Он аналогичен 301 Moved Permanently за тем исключением, что будет использоваться тот же метод HTTP, что и в предыдущем запросе.

4xx коды состояния (ошибка клиента)

Код состояния

Описание

400 Неверный запрос

Сервер не может понять запрос из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.

401 Неавторизованный

Указывает, что для запроса требуется информация для аутентификации пользователя. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка авторизации

402 Требуется оплата (экспериментальная)

Зарезервировано для использования в будущем. Он предназначен для использования в цифровых платежных системах.

403 Запрещено

Несанкционированный запрос. У клиента нет прав доступа к содержимому. В отличие от 401, личность клиента известна серверу.

404 Не найдено

Сервер не может найти запрошенный ресурс.

405 Метод не разрешен

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

406 Неприемлемо

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

407 Требуется аутентификация прокси-сервера

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

408 Время ожидания запроса

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

409 Конфликт

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.

410 Исчез

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

411 Требуемая длина

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

412 Предусловие не выполнено

Клиент указал в своих заголовках предварительные условия, которым сервер не соответствует.

413 Объект запроса слишком велик

Объект запроса превышает ограничения, установленные сервером.

414 Request-URI Too Long

URI, запрошенный клиентом, длиннее, чем может интерпретировать сервер.

415 Неподдерживаемый тип носителя

Тип носителя в Тип содержимого запроса не поддерживается сервером.

416 Запрошенный диапазон невыполним

Диапазон, указанный в поле заголовка Range в запросе, не может быть выполнен.

417 Ожидание не оправдалось

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

418 Я чайник (RFC 2324)

Это было определено как апрельская шутка и не ожидается, что оно будет реализовано реальными HTTP-серверами. (RFC 2324)

420 Enhance Your Calm (Twitter)

Возвращается API поиска и трендов Twitter, когда скорость клиента ограничена.

422 Необрабатываемый объект (WebDAV)

Сервер понимает тип содержимого и синтаксис объекта запроса, но по какой-то причине сервер не может обработать запрос.

423 Заблокировано (WebDAV)

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

424 Неудачная зависимость (WebDAV)

Запрос не выполнен из-за сбоя предыдущего запроса.

425 Слишком рано (WebDAV)

Указывает, что сервер не хочет рисковать обработкой запроса, который может быть воспроизведен.

426 Требуется обновление

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

428 Требуется предварительное условие

Исходный сервер требует, чтобы запрос был условным.

429 Слишком много запросов

Пользователь отправил слишком много запросов за заданный период времени («ограничение скорости»).

431 Поля заголовка запроса слишком велики

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

444 Нет ответа (Nginx)

Сервер Nginx не возвращает клиенту никакой информации и закрывает соединение.

449 Повторить с помощью (Microsoft)

Запрос следует повторить после выполнения соответствующего действия.

450 Заблокировано родительским контролем Windows (Microsoft)

Родительский контроль Windows включен и блокирует доступ к данной веб-странице.

451 Недоступно по юридическим причинам

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

499 Запрос клиента (Nginx)

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

5xx кодов состояния (ошибка сервера)

Код состояния

Описание

500 Ошибка внутреннего сервера

333392. Сервер, который не был неожиданным.

501 Не реализовано

Метод HTTP не поддерживается сервером и не может быть обработан.

502 Bad Gateway

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

503 Служба недоступна

Сервер не готов обработать запрос.

504 Время ожидания шлюза

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

505 Версия HTTP не поддерживается (экспериментальная)

Версия HTTP, используемая в запросе, не поддерживается сервером.

506 Вариант также согласовывается (экспериментальный)

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

507 Недостаточно памяти (WebDAV)

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

508 Обнаружен цикл (WebDAV)

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

510 Не расширен

Для выполнения сервером требуются дополнительные расширения запроса.

511 Требуется сетевая аутентификация

Указывает, что клиент должен пройти аутентификацию для получения доступа к сети.

6.

Специальные коды состояния HTTP REST
200 (ОК)

Это указывает на то, что REST API успешно выполнил любое действие, запрошенное клиентом, и что более конкретный код из серии 2xx не подходит.

В отличие от кода состояния 204, ответ 200 должен включать тело ответа. Информация, возвращаемая с ответом, зависит от метода, использованного в запросе, например:

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

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

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

Исходный сервер ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер ДОЛЖЕН вместо этого ответить ответом 202 (принято).

202 (Принято)

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

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

Объекту, возвращаемому с этим ответом, СЛЕДУЕТ включать указание текущего состояния запроса и либо указатель на монитор состояния (местоположение очереди заданий), либо некоторую оценку того, когда пользователь может ожидать выполнения запроса.

204 (без содержимого)

Код состояния 204 обычно отправляется в ответ на запрос PUT , POST или DELETE , когда REST API отказывается отправлять обратно какое-либо сообщение о состоянии или представление в ответе. тело сообщения.

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

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

Ответ 204 НЕ ДОЛЖЕН включать тело сообщения и поэтому всегда заканчивается первой пустой строкой после полей заголовка.

301 (перемещено навсегда)

Код состояния 301 указывает на то, что модель ресурсов REST API была значительно переработана, а запрошенному клиентом ресурсу был назначен новый постоянный URI. REST API должен указать новый URI в заголовке Location ответа, и все будущие запросы должны быть направлены на данный URI.

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

302 (Найдено)

Код состояния ответа HTTP 302 Найдено — это распространенный способ выполнения перенаправления URL-адресов. Ответ HTTP с этим кодом состояния дополнительно предоставит URL-адрес в поле заголовка Location. Пользовательский агент (например, веб-браузер) приглашается ответом с этим кодом сделать второй. В противном случае идентично, запросите новый URL-адрес, указанный в поле местоположения.

Многие веб-браузеры реализовали этот код таким образом, который нарушил этот стандарт, изменив тип запроса нового запроса на GET, независимо от типа, использованного в исходном запросе (например, POST). В RFC 1945 и RFC 2068 указано, что клиенту не разрешено изменять метод перенаправленного запроса. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно указать, какая реакция ожидается от клиента.

303 (см. Другое)

Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки потенциально нежелательного тела ответа он отправляет клиенту URI ресурса ответа. Ответом может быть URI временного сообщения о состоянии или URI какого-либо уже существующего, более постоянного ресурса.

Вообще говоря, код состояния 303 позволяет REST API отправлять ссылку на ресурс, не заставляя клиента загружать его состояние. Вместо этого клиент может отправить запрос GET на значение заголовка Location.

Ответ 303 НЕ ДОЛЖЕН кэшироваться, но ответ на второй (перенаправленный) запрос может кэшироваться.

304 (не изменено)

Этот код состояния аналогичен 204 («Нет содержимого») в том смысле, что тело ответа должно быть пустым. Критическое различие заключается в том, что 204 используется, когда в теле нечего отправлять, тогда как 304 используется, когда ресурс не был изменен с версии, указанной в заголовках запроса If-Modified-Since или If-None-Match.

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

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

307 (Временное перенаправление)

Ответ 307 означает, что REST API не собирается обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URI, указанный в заголовке Location ответного сообщения. Однако в будущих запросах по-прежнему должен использоваться исходный URI.

REST API может использовать этот код состояния для назначения временного URI запрошенному клиентом ресурсу. Например, ответ 307 можно использовать для переноса запроса клиента на другой хост.

Временный URI СЛЕДУЕТ указывать в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новые URI. Если код состояния 307 получен в ответ на запрос, отличный от GET или HEAD , пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых был отправлен запрос.

400 (неверный запрос)

400 — это общий статус ошибки на стороне клиента, используемый, когда никакой другой код ошибки 4xx не подходит. Ошибки могут быть такими, как искаженный синтаксис запроса, недопустимые параметры сообщения запроса или вводящая в заблуждение маршрутизация запроса и т. д.

Клиент НЕ ДОЛЖЕН повторять запрос без изменений.

401 (Неавторизованный)

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

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

403 (Forbidden)

Ответ с ошибкой 403 свидетельствует о том, что запрос клиента сформирован правильно, но REST API отказывается его выполнять, т. е. пользователь не имеет необходимых прав доступа к ресурсу. Ответ 403 не является случаем недостаточности учетных данных клиента; это будет 401 («Неавторизованный»).

Аутентификация не поможет, и запрос НЕ ДОЛЖЕН повторяться. В отличие от ответа 401 Unauthorized, аутентификация не имеет значения.

404 (не найдено)

Код состояния ошибки 404 указывает на то, что REST API не может сопоставить URI клиента с ресурсом, но может быть доступен в будущем. Последующие запросы от клиента допустимы.

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

405 (Метод не разрешен)

API отвечает ошибкой 405, указывающей, что клиент пытался использовать метод HTTP, который не разрешен ресурсом. Например, ресурс только для чтения может поддерживать только GET и HEAD, тогда как ресурс контроллера может разрешать GET и POST, но не PUT или DELETE.

Ответ 405 должен включать заголовок Allow, в котором перечислены методы HTTP, поддерживаемые ресурсом. Например:

 Разрешить: GET, POST 
406 (Неприемлемо)

Ответ об ошибке 406 указывает на то, что API не может генерировать ни один из предпочтительных типов мультимедиа клиента, как указано в заголовке запроса Accept. Например, клиентский запрос данных в формате application/xml получит ответ 406, если API готов отформатировать данные только как application/json .

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

412 (ошибка предварительного условия)

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

415 (неподдерживаемый тип носителя)

Ответ об ошибке 415 указывает на то, что API не может обработать предоставленный клиентом тип носителя, как указано в заголовке запроса Content-Type. Например, запрос клиента, включающий данные в формате application/xml получит ответ 415, если API готов обрабатывать данные только в формате application/json .

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

500 (внутренняя ошибка сервера)

500 — это общий ответ об ошибке REST API. Большинство веб-фреймворков автоматически отвечают этим кодом состояния ответа всякий раз, когда они выполняют какой-либо код обработчика запросов, вызывающий исключение.

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

Ответ API — это общее сообщение об ошибке, выдаваемое при возникновении непредвиденной ситуации, когда не подходит более конкретное сообщение.

501 (Не реализовано)

Сервер либо не распознает метод запроса, либо не может выполнить запрос. Обычно это подразумевает доступность в будущем (например, новая функция API веб-сервиса).

Ссылки:

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Список кодов состояния HTTP | Объяснение кодов ошибок HTTP

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

Эти коды состояния HTTP или коды сетевых ошибок будут отображаться в результатах сеанса мониторинга, а также в уведомлениях о предупреждениях. Эти коды состояния поддерживаются Управлением по присвоению номеров в Интернете (IANA), и самый последний список кодов можно найти здесь.

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

 

Wh a t это протокол HTTP ?  

Каждый раз, когда пользователь посещает веб-сайт, он отправляет запрос из своего браузера/клиента на сервер, который отвечает запрошенными ресурсами. Все эти запросы соответствуют стандарту HTTP (протокол передачи гипертекста). Протокол HTTP, технически являющийся частью прикладного уровня в наборе протоколов Интернета, – это всего лишь один из множества протоколов в наборе IP. Протокол HTTP — это основа Интернета, используемая для связи и отправки данных между клиентами и серверами. Некоторые из других наиболее распространенных интернет-протоколов, с которыми вы сталкивались, включают следующее: 

 

Прикладной уровень  Протоколы  

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

  • DNS : Протокол DNS (система доменных имен) преобразует доменные имена в удобочитаемые IP-адреса для браузера, чтобы можно было загружать ресурсы.
  • FTP : Протокол FTP (протокол передачи файлов) используется для передачи файлов между браузером и сервером в компьютерной сети.
  • SMTP : протокол SMTP (простой протокол передачи почты) используется для отправки и получения электронной почты между отправителями и получателями в сети.
  • TLS/ SSL : протокол SSL (Secure Sockets Layer) официально признан устаревшим в 2015 году. Вместо него был введен TLS (Transport Layer Security), чтобы обеспечить безопасный способ связи по сети.
  • IMAP : Протокол IMAP (протокол доступа к сообщениям в Интернете) используется для управления и получения сообщений с сервера электронной почты. В отличие от SMTP, вы не можете использовать протокол IMAP для отправки сообщений электронной почты.
  • POP : протокол POP (протокол почтового отделения) похож на IMAP, но разница в том, что протокол POP позволяет пользователю получать сообщения с сервера электронной почты, но затем сообщение удаляется с сервера электронной почты. Протокол IMAP может синхронизировать сообщения между несколькими устройствами. Это действительно зависит от того, как вы хотите, чтобы пользователи получали доступ к своей электронной почте.
  • SIP : протокол SIP (протокол инициации сеанса) — это протокол сигнализации, который используется в приложениях для передачи голоса, видео и сообщений в режиме реального времени. SIP – это протокол, который используется для включения и развертывания услуг VoIP (Voice Over Internet Protocol). SIP также используется в сочетании с другими протоколами, такими как SDP (протокол описания сеанса), UDP, TCP и TLS, для передачи данных сеанса и мультимедиа.

 

Транспортный уровень  Протоколы  

Транспортный уровень обрабатывает передачу данных, которая также включает протоколы TCP и UDP, и обеспечивает правильную и своевременную отправку и получение данных.

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

 

Интернет-уровень  Протоколы  

Интернет-уровень, также называемый сетевым уровнем, отвечает за отправку и сборку сетевых пакетов наиболее эффективным способом с использованием сетевых адресов/IP-адресов для отправки пакетов к месту назначения.

  • IP . Протокол IP (интернет-протокол) вместе с протоколом TCP представляет собой набор требований, определяющих способ отправки данных через Интернет.
  • ICMP : протокол ICMP (Internet Control Message Protocol) — это сетевой протокол, который позволяет сетевым устройствам, таким как маршрутизаторы, диагностировать проблемы со связью. Протокол ICMP не связан с обменом данными, его цель — убедиться, что данные достигают назначенного места назначения.

 

Канальный уровень  Протоколы  

Канальный уровень – это группа методов связи, которая управляет передачей данных между физическими устройствами и сетью.

  • ARP : протокол/процедура ARP (протокол разрешения адресов) для сопоставления сетевых IP-адресов с адресом физического аппаратного устройства, также известным как MAC-адрес.
  • MAC : протокол MAC (управление доступом к среде) присваивает аппаратным устройствам их уникальный идентификационный номер. Он обеспечивает способ для сетей подключаться и взаимодействовать с устройствами.
  • Wi-Fi : Протокол Wi-Fi (Wireless Fidelity), который является одним из протоколов, на которые все мы полагаемся в повседневной жизни, представляет собой группу протоколов беспроводной сети, которые используются для подключения к Интернету и ЛВС (локальные сети).

 

Что такое коды состояния и почему они важны?  

Существуют даже расширения протокола HTTP, в том числе HTTPS (защищенный протокол передачи гипертекста) и WebDAV (распределенное создание и управление версиями через Интернет), которые мы подробнее обсудим в кодах состояния HTTP ниже. Когда клиент отправляет запрос на сервер, коды состояния позволяют узнать, был ли запрос успешным, неудачным или чем-то другим. Коды состояния поддерживаются Управлением по присвоению номеров в Интернете, или IANA, и включают коды состояния от Инженерной группы Интернета (IETF) и Общества Интернета (ISOC). Согласно определению организации IANA, существует пять классификаций кодов состояния HTTP: 9.0003

1xx : Информационное — запрос получен, процесс продолжается
2xx : Успех — действие было успешно получено, понято и принято
3xx : Перенаправление — необходимо предпринять дальнейшие действия для выполнения запроса
4xx : Ошибка клиента — запрос содержит неверный синтаксис или не может быть выполнен
5xx : Ошибка сервера — серверу не удалось выполнить кажущийся действительным запрос

Отдельные лица и инженеры регулярно предлагают новые коды состояния через запросы комментариев (RFC), и IETF рассмотрит, примет и упразднит коды статуса по мере необходимости.

 

Объяснение кодов состояния HTTP  

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

Первая цифра кода состояния идентифицирует класс; однако вторые две цифры не играют никакой роли в дальнейшем определении кода состояния для определенного типа сообщения/ответа. Внутри этих групп классификации может быть несколько кодов состояния, и некоторые группы имеют больше кодов состояния, чем другие. И хотя официально существует более 60 уникальных кодов статуса, большинство людей со временем будут регулярно сталкиваться лишь с несколькими или двумя примерами.

Большинство этих кодов состояния интерпретируются и обрабатываются за кулисами. Вы также увидите, что есть группы кодов, помеченные как «Не назначенные». Хотя большинство кодов состояния, которые мы видим сегодня, были стандартизированы и не менялись с течением времени, эти неназначенные номера оставляют место для создания дополнительных кодов состояния по мере необходимости. Кроме того, несмотря на то, что некоторые из неназначенных кодов пользователей ранее не были частью стандарта HTTP (протокол передачи гипертекста), есть компании, которые используют их в качестве настраиваемого ответа сервера для пользователей, что позволяет компаниям лучше устранять проблемы, с которыми могут столкнуться пользователи. Нажмите на ссылку справочного документа RFC в списке ниже, чтобы получить полную информацию о конкретном коде состояния HTTP.

Полный список и обзор кодов статуса HTTP

1 XX CODE S : Информация S . то, что они сделали, было получено, но все еще обрабатывается. Коды состояния 1xx не обязательно означают наличие проблемы, они просто указывают на то, что что-то все еще находится в процессе завершения. В эту группу включено лишь несколько кодов 1xx, с которыми пользователи могут столкнуться и о которых нужно знать.

 

100 : Продолжить

Код состояния 100 Продолжить сообщает вам, что часть запроса получена без проблем. На данный момент все в порядке, но все еще в процессе. Если оставшаяся часть запроса не будет отклонена, сервер отправит окончательный ответ после завершения запроса. Если заголовки HTTP были отклонены, это гарантирует, что клиент не отправит запрос на получение тела. Однако если запрос не содержит поля заголовка, браузер просто проигнорирует ответ. Дополнительную информацию см. в RFC7231, раздел 6.2.1.

 

101: Переключение протоколов

С момента скромного появления Интернета было создано множество протоколов HTTP. Первой задокументированной версией протокола HTTP был HTTP 0.9. Текущая версия — HTTP 2.0 или HTTP/2. Код состояния 101 Switching Protocols указывает, что сервер принимает запрос от клиента на переключение на другой протокол HTTP через поле заголовка Upgrade. Когда браузер отправляет запрос на страницу, он может получить код состояния HTTP 101, а затем заголовок Upgrade, который указывает, что сервер переключается на другую версию HTTP. Наконец, предполагается, что сервер согласится переключать протоколы только тогда, когда это выгодно, например, при обновлении или переключении на новый протокол вместо старого. Дополнительную информацию см. в RFC7231, раздел 6.2.2.

 

102: Обработка

Код состояния 102 Обработка используется только с WebDAV (веб-распределенное создание и управление версиями). Большинство страниц доступны только для чтения. WebDAV – это расширение протокола HTTP, которое дает клиентам возможность удаленно редактировать контент и передавать файлы. Протокол WebDAV был создан, чтобы дать пользователям возможность совместно работать над файлами с другими пользователями, такими как Dropbox или Google Диск. Код состояния 102 — это промежуточный код ответа, сообщающий клиенту, что сервер принял полный запрос, но еще не выполнил запрос. Этот код состояния HTTP отправляется сервером только в том случае, если запрос занимает более 20 секунд. Дополнительную информацию см. в RFC2518, раздел 10.2.

 

103: Ранние подсказки

Коды состояния 103 Ранние подсказки в настоящее время находятся на оценочной/экспериментальной стадии. Этот код состояния будет использоваться при предварительной загрузке внешнего контента/ресурсов. Протокол HTTP/2 позволяет передавать контент для ускорения доставки, поэтому веб-разработчики могут отправлять определенный контент, ожидая загрузки других внешних ресурсов. Это выгодно с точки зрения конечного пользователя, поскольку сводит к минимуму воспринимаемое время загрузки. Этот код ответа HTTP указывает браузеру, что сервер собирается отправить окончательный ответ вместе с полями заголовка, включенными в ответ. См. RFC829.7, раздел 2 для получения дополнительной информации.

 

2xx Код состояния: Успех  

Коды состояния HTTP уровня 2xx указывают, что запрос клиента от сервера был успешно получен и обработан. В отличие от кодов состояния 4xx, коды состояния 2xx — это то, что вы хотите получить. Как и коды состояния 1xx, коды состояния 2xx обрабатываются за кулисами и редко видны пользователям, если только они не используют инструменты разработчика или SEO для просмотра всех HTTP-ответов страницы.

 

200: OK

Один из наиболее широко используемых кодов состояния HTTP, код состояния 200 OK используется для обозначения того, что запрос был получен, обработан и выполнен успешно. Однако в зависимости от используемого метода запроса (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). Например, если запрос является запросом GET, ответ будет включать ресурс. Если это любой другой запрос, ответ будет включать результат действий. Код состояния 200 — это один из более чем 10 других кодов ответа, который также можно кэшировать, что означает, что его можно сохранить и получить через клиент, чтобы в будущем не приходилось делать еще один запрос на сервер. Дополнительную информацию см. в RFC7231, раздел 6.3.1.

 

201: Created

Код статуса 201 Created подобен коду статуса 200 OK, однако код статуса 201 означает, что запрос был успешно обработан, и он вернул или создал ресурс или ресурсы в процесс. Код состояния 201 обычно используется для запросов PUT. Например, когда используется запрос PUT, новый ресурс создается по URL-адресу, указанному в запросе. Если в запросе POST есть код состояния 201, это означает, что ресурс был создан в другой конечной точке или местоположении API. Дополнительную информацию см. в RFC7231, раздел 6.3.2.

 

202: Accepted

Код статуса 202 Accepted означает, что сервер получил запрос на обработку, и он принят, но запрос не выполнен. Это также не означает, что запрос в конечном итоге будет принят, так как это будет зависеть от того, когда произойдет фактическая обработка. Этот тип запроса обычно встречается в API, где пакетный процесс запускается один раз в день. Поскольку HTTP не может обмениваться данными после успешного выполнения запроса или закрытия соединения пользователя, API может отправить пользователю электронное письмо с уведомлением об успешном выполнении процесса. Дополнительную информацию см. в RFC7231, раздел 6.3.3.

  

203: Недостоверная информация

Код статуса 203 Недостоверная информация обычно используется прокси-сервером HTTP или третьей стороной. Прокси, находящийся между клиентом и сервером, может изменить ответы до того, как достигнет клиента. Чтобы указать, что в процессе что-то изменилось, используется код состояния 203. Однако недостатком этого метода является то, что невозможно узнать исходный код состояния, если прокси изменил что-то в ответе. Предлагаемый обходной путь — использовать заголовок предупреждения вместе с кодом состояния 214, который используется для указания на изменение или модификацию ответа. Использование заголовка предупреждения позволяет передать исходный код состояния. Дополнительную информацию см. в RFC7231, раздел 6.3.4.

 

204: Нет контента

Код состояния 204 Нет контента указывает, что ответ был успешно доставлен сервером и выполнен, и в теле ответа не должно быть отправлено никакого другого контента. Например, если запрос отправляется в форме на странице, после отправки ответа клиент/браузер не должен изменять представление, то есть форма не должна обновляться или направлять пользователей на новую страницу. Никакой дополнительный контент не должен заменяться или отображаться с точки зрения пользователя. Дополнительную информацию см. в RFC7231, раздел 6.3.5.

 

205: Сбросить содержимое  

Как и код состояния 204 Нет содержимого, код состояния 205 Сбросить содержимое указывает, что сервер успешно отправил запрос, и требует от агента пользователя обновить/сбросить представление в исходное состояние. . Если мы используем пример формы на странице, то после того, как пользователь заполнит и отправит форму, клиент/браузер должен вернуть форму в исходное состояние, чтобы пользователь мог предпринять дальнейшие действия. Код состояния 205 предполагает, что дальнейший контент предоставляться не будет. Дополнительную информацию см. в RFC7231, раздел 6.3.6.

 

206:  Partial Content

Код состояния 206 Partial Content может использоваться для различных запросов и обычно указывает на то, что сервер частично выполнил запрос. Например, если клиент ищет только определенную часть или диапазон определенного ресурса или страницы. Еще один пример использования кода состояния 206 – видео. Клиент может загружать видео только по частям, чтобы не ждать буферизации или загрузки видео, помогая избежать отрицательного пользовательского опыта, когда пользователю придется ждать дольше, прежде чем видео начнет воспроизводиться. Это обычная передовая практика среди видеопроигрывателей HTTP, позволяющая избежать проблем с пропускной способностью и предполагаемой задержкой. Дополнительную информацию см. в RFC7233, раздел 4.1.

 

207: Multi-Status

Код статуса 207 Multi-Status предоставляет статус для нескольких независимых процессов и используется серверами WebDAV. Сообщение/ответ по умолчанию представляет собой текстовое/XML-сообщение. Это указывает на то, что было выполнено несколько операций и что статус каждой операции можно просмотреть в тексте ответа. Коды состояния могут варьироваться в любой из пяти категорий. Коды ответов будут различаться в зависимости от количества подзапросов. В отличие от других кодов состояния 200, код состояния 207 не подтверждает успешность процесса. Клиенту необходимо просмотреть текст каждого запроса, чтобы определить, был ли он успешным или нет. См. RFC49.18, раздел 11.1 для получения дополнительной информации.

 

208: Уже сообщено  

Код состояния 208 Уже сообщено – это еще один код состояния, используемый в расширении WebDAV. Как и код состояния 207, он позволяет клиенту/браузеру указать серверу, что ресурс уже обработан. Когда клиент запрашивает ресурсы, ответ может содержать повторяющиеся ресурсы, что будет означать, что одни и те же ресурсы будут отправлены несколько раз, что является избыточным. Статусный ответ 208 исключает возможность обработки и повторения одного и того же ответа. Ответы с кодом состояния 208 будут отображаться только в теле ответа и никогда не будут отображаться как фактический ответ HTTP. Дополнительную информацию см. в RFC5842, раздел 7.1.

 

209-225: Не назначено  

Коды состояния с 209 по 225 в настоящее время не назначены.

 

226:  IM  Used

несколько манипуляций с экземпляром, примененных к текущему экземпляру. В протоколе HTTP есть расширение, называемое дельта-кодированием в HTTP, которое поддерживается на стороне сервера. Если это реализовано, клиент может запросить изменения кешированной версии, и сервер отправит изменения вместо повторной отправки всего ресурса снова. Чтобы реализовать эту функцию, в запросе клиента или браузера необходимо указать поддерживаемый тип обмена мгновенными сообщениями. Если сервер также поддерживает эту функцию, он ответит кодом состояния 226 и изменениями. Если в ответ возвращается код состояния 200, это означает, что функция не поддерживается. См. RFC3229., Раздел 10.4.1 для получения дополнительной информации.

 

227-299: Не назначено

Коды состояния с 227 по 299 в настоящее время не назначены.

 

3xx: перенаправление  

Коды состояния 3xx используются в случаях перенаправления URL. Веб-сайты постоянно меняются и развиваются, поэтому иногда маркетологам необходимо направлять пользователей на обновленную или другую страницу. Перенаправления помогают избавить пользователей от необходимости искать то, что они ищут, и поддерживать ваш рейтинг в поисковых системах. Действия по перенаправлению могут выполняться браузером автоматически или требовать дополнительного взаимодействия со стороны пользователей. Коды состояния HTTP 3xx жизненно важны для SEO (поисковая оптимизация) и взаимодействия с пользователем, а также сообщают поисковым системам, какой контент вы хотите, чтобы они сканировали и индексировали. Если это не реализовано должным образом, пользователи могут быть перенаправлены в непредусмотренное место, что может привести к коду состояния 4xx и может повлиять на показатели качества SEO.

 

300: Multiple Choices

Код статуса 300 Multiple Choices указывает на то, что ресурс перемещен и может перенаправляться в несколько местоположений. В этом случае пользователь должен решить, какой ресурс использовать. Сервер может указать предпочтительный вариант, и это должно быть указано в поле заголовка, где пользовательский агент может автоматически перенаправить на предпочтительный вариант. На практике этот код состояния используется редко, поскольку не существует стандартизированного способа выбора из нескольких ответов. Дополнительную информацию см. в RFC7231, раздел 6.4.1.

 

301: Перемещено навсегда

Код состояния 301 Перемещено навсегда используется для обозначения того, что целевой ресурс был перемещен в постоянное место. Код состояния 301 указывает браузеру/клиенту использовать это новое местоположение или URL-адрес в заголовке. Вместе с кодом статуса 301 в ответе будет указан новый URL-адрес, а также обновлены все URL-адреса в предыдущих местоположениях вместе с обновлением до нового URL-адреса. Дополнительную информацию см. в RFC7231, раздел 6.4.2.

 

302: Found

Код статуса 302 Found указывает клиенту/браузеру, что ресурс, к которому они обращаются, временно находится в другом месте. В отличие от кода состояния 301, код состояния 302 указывает на временное перемещение, поэтому клиент не должен автоматически обновлять свои ссылки на новое местоположение, поскольку, опять же, это должно быть временным. Пример того, где следует использовать код состояния 302, если URL-адресов несколько, но они могут отображаться на разных языках. Пользователь может перейти по определенному URL-адресу, но клиент может автоматически перенаправить его на нужную страницу в зависимости от настроек браузера и использовать ее при последующих посещениях. Отмечается, что в некоторых случаях браузеры могут изменить запрос с POST на GET. В случае, если это действие не является благоприятным, следует использовать код состояния 307. Дополнительную информацию см. в RFC7231, раздел 6.4.3.

 

303: см. другое

Код состояния 303 см. другое указывает, что сервер будет перенаправлять клиент/браузер на другой ресурс. Ресурс будет указан в виде URL в поле заголовка. В отличие от кодов состояния 301 и 302, это не означает, что ресурс был временно или постоянно перемещен, его цель состоит в том, чтобы указать URL-адрес, по которому можно найти ответ на конкретный запрос с помощью запроса GET. Коды состояния 303 не должны кэшироваться, однако ответ на последующий запрос может быть кэширован. Обычно код состояния 303 используется для того, чтобы пользователи случайно не отправили данные формы повторно через POST-запрос. Они должны быть направлены на новую страницу. В противном случае они могут неосознанно нажать кнопку "Назад" в своем браузере, что может привести к повторной отправке запроса, что приведет к ненужным дубликатам. Дополнительную информацию см. в RFC7231, раздел 6.4.4.

 

304: Не изменено

В ответ на условный запрос GET или HEAD отправляется код состояния 304 Не изменено. Клиенты/браузеры могут отправлять условный запрос, например If-Match , If-None-Match , If-Modified-Since , If-Unmodified-Since или If-Range , запрашивая конкретный ресурс был изменен с определенной даты/времени. Это делается только в том случае, если клиент ранее обращался к ресурсу, скачивал и сохранял его. Если он был изменен с момента последнего доступа к указанной дате/времени, сервер вернет код состояния 200 OK. Если он не менялся с этой даты/времени, в качестве ответа отправляется код состояния 304, указывающий, что сохраненный ресурс должен быть обслужен, поскольку он не изменялся с момента последнего доступа к нему. Дополнительную информацию см. в RFC7232, раздел 4.1.

 

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

Код состояния 305 Использовать прокси – это устаревший код состояния, который больше не используется из соображений безопасности. Он использовался, чтобы указать клиенту, что доступ к ресурсу, к которому он обращается, должен осуществляться через прокси. Для получения дополнительной информации о коде состояния прокси 305, см. RFC7231, раздел 6.4.5

306: Неиспользованный

, как код состояния 305, статус 306 неиспользованный статус был первоначально известен, как выключите. Код состояния 306 использовался в предыдущей спецификации. Его предназначение состояло в том, чтобы указать клиенту, что последующие запросы к ресурсу должны использовать указанный прокси. Это было сочтено проблемой безопасности, поэтому больше не используется. Дополнительные сведения о коде состояния 306 Unused см. в RFC7231, раздел 6.4.6   9.0003

 

307: Временное перенаправление  

Как и код состояния перенаправления 302 Found, код состояния 307 Temporary Redirect указывает клиенту/браузеру, что ресурс или документ доступен по другому временному URL-адресу, и возвращает этот URL-адрес. Поскольку перенаправление является временным и может измениться, браузер/клиент должен продолжать обращаться к текущему URL-адресу для последующих запросов. Основное различие между кодом состояния 302 и кодом состояния 307 заключается в том, что код состояния 307 не позволяет изменять запросы с POST-запроса на GET-запрос, поэтому, если клиент запросил POST-запрос, он будет перенаправлен и снова инициирует POST-запрос. . См. RFC7231, раздел 6.4.7   9.0003

 

308: постоянное перенаправление  

Код состояния постоянного перенаправления 308 – это код состояния, который можно кэшировать (если не реализованы элементы управления кэшированием), который указывает, что целевой ресурс теперь находится по постоянному URL-адресу, и последующие запросы должны быть направлены на этот URL-адрес. Кроме того, клиент должен обновить все старые закладки до нового местоположения. Код состояния 308 очень похож на код состояния 301, однако, если отправляется код состояния 308, клиент должен инициировать и отправить тот же запрос в целевом местоположении. Код состояния 301 не обязателен для этого. Большинство браузеров/клиентов меняют запрос POST на запрос GET. Дополнительную информацию см. в RFC7238, раздел 3 .

 

309-399: Не назначено

Коды состояния с 309 по 399 в настоящее время не назначены.

 

4xx: Ошибка клиента  

Классификация с наибольшим количеством кодов состояния HTTP, 4xx коды состояния HTTP — это не то, что вы хотите, чтобы ваши пользователи видели. Любой код состояния, начинающийся с цифры 4, означает, что с клиентом возникла проблема. Коды состояния 4xx обычно генерируются, если страница была удалена и не перенаправлена, или что-то неправильно введено в URL-адресе или ссылке. Если пользователи получают страшный код состояния 4xx, это означает, что существует проблема с получением клиентом/браузером информации с сервера. Это ошибки, которые пользователи увидят во всплывающем окне на своем экране и создадут негативный пользовательский опыт, что приведет к небольшому разочарованию, и они будут искать что-то еще. Например, если поисковые системы сканируют ваш сайт и получают ошибку 404, это будет отображаться как ошибка в отчете. Несколько ошибок 404 — это нормально, и поисковые системы не обязательно считают их чем-то негативным, но 404, перенаправляющая на 404, может негативно повлиять на вашу поисковую оптимизацию. Мало того, если рассматриваемая страница используется для увеличения трафика или продаж, это может привести к потере потенциального дохода.

 

400: Bad Request

Код статуса ошибки 400 Bad Request означает, что сервер не может обработать запрос из-за проблемы со стороны клиента. Это может быть вызвано рядом причин, например слишком большим файлом, неправильным синтаксисом, недопустимым URL-адресом или какой-либо другой проблемой, вызванной сторонним приложением, поэтому код состояния 400 иногда используется в качестве уловки. весь код состояния, даже если есть проблема на стороне сервера. Это может сделать устранение неполадок с кодом состояния 400 немного более трудоемким и сложным, однако, наряду с ошибкой кода состояния 400 и информацией заголовка, сервер может предоставить дополнительный ответ вместе с ним, который может отображаться пользователю, чтобы помочь идентифицировать проблема и облегчить процесс устранения неполадок и диагностики ошибки. Дополнительную информацию см. в RFC7231, раздел 6.5.1.

  

401: Unauthorized

Код статуса 401 Unauthorized error указывает, что запрос не содержит соответствующих учетных данных аутентификации, аутентификация не удалась или пользователь должен войти в систему. Клиент требует аутентификации от сервера. Термины авторизованный и аутентифицированный часто взаимозаменяемы, но означают разные вещи. Код состояния 401 строго связан с аутентификацией. В тех случаях, когда вы хотите сообщить клиенту, что он вообще не разрешен, следует реализовать код состояния 403 . Согласно спецификации, код статуса 401 должен также включать WWW-Authenticate  Заголовок ответа сервера, указывающий клиенту, какая схема или метод аутентификации требуется серверу. Дополнительную информацию см. в RFC7235, раздел 3.1.

 

402: Payment Required  

Первоначально созданный как часть способа, позволяющего использовать потенциальные будущие цифровые методы оплаты, код ошибки 402 Payment Required официально зарезервирован для будущего использования, но он используется, но ограниченно , ситуации. Дополнительную информацию о коде ошибки 402 Payment Required см. в RFC7231, раздел 6.5.2    9.0003

  

403: Запрещено

Код статуса ошибки 403 Запрещено указывает, что запрос от клиента был понят, но сервер не авторизует его, поэтому клиент не может получить к нему доступ. Сервер может указать причину, по которой он не авторизует запрос в ответе, что может быть вызвано различными причинами, такими как неправильный пароль или имя пользователя. В отличие от кода состояния 401, который требует аутентификации, код состояния 403 может указывать на то, что у клиента действительно нет авторизации для доступа к этим ресурсам, поэтому аутентификация в этом случае невозможна. Дополнительную информацию см. в RFC7231, раздел 6.5.3.

 

404: Not Found

Один из самых распространенных и печально известных кодов состояния, с которыми сталкиваются пользователи и разработчики, код ошибки 404 Not Found указывает, что ресурс, требуемый от сервера, не существует или не хочет предоставить его клиенту. Код состояния 404 не указывает, является ли отсутствие предоставления ресурса временным или постоянным, но клиент может делать последующие запросы на доступ к нему. В случаях, когда известно, что ресурсы исчезли безвозвратно, следует использовать код состояния 410. Коды состояния 404 по умолчанию также кэшируются, если не установлены другие элементы управления кэшированием. Дополнительную информацию см. в RFC7231, раздел 6. 5.4.

 

405: Метод не разрешен

Код статуса ошибки 405 "Метод не разрешен" указывает, что конкретный ресурс, запрошенный клиентом, не поддерживается сервером. Метод 405 Not Allowed похож на код состояния 403 Forbidden, однако код состояния 403 указывает, что ресурс может быть доступен, просто у клиента нет необходимых полномочий для выполнения запроса. Наряду со статусом 405 Method Not Allowed сервер должен указать соответствующие и поддерживаемые методы для целевого ресурса. Дополнительные сведения о коде ошибки 405 Method Not Allowed см. в RFC7231, раздел 6.5.5   9.0003

 

406: Неприемлемо

Как и код ошибки 405 «Метод не разрешен», код ошибки 406 «Недопустимо» указывает на отсутствие поддержки для определенного запроса. В этом случае код статуса 406 Not Acceptable указывает на то, что сервер понял запрос, но ответ не поддерживается или не понят клиентом. Клиент может запросить определенные версии ресурса в заголовке, такие как A-IM или Accept Language, среди прочего, но если сервер не поддерживает это, он отвечает кодом состояния 406 Not Acceptable. Сервер может либо ответить списком подходящих идентификаторов ресурсов, из которых клиент может выбрать. Дополнительную информацию см. в RFC7231, раздел 6.5.6.

  

407: Proxy Authentication Required

Код ошибки 407 Proxy Authentication Required похож на код состояния 401 Unauthorized, однако в случае кода состояния 407 для использования прокси-сервера клиент должен сначала пройти аутентификацию. Прокси должен вернуть метод аутентификации. Прокси-серверы, которые сегодня не так распространены из-за роста популярности VPN, выступают в качестве посредников между пользователями/клиентами и Интернетом, позволяя пользователям быстрее получать доступ к ресурсам, поскольку контент обычно кэшируется, а также могут обеспечивать уровень безопасности и анонимности для пользователей. Дополнительную информацию о коде ошибки 407 Proxy Authentication Required см. в RFC7235, раздел 3.2  9.0003

 

408: Время ожидания запроса

Код ошибки 408 Время ожидания запроса означает, что сервер не получил запрос от клиента в течение заданного периода времени. Отложенный запрос от клиента может быть вызван различными причинами, такими как медленное или разорванное соединение. По истечении этого времени сервер отправляет статус 408 Request Timeout, и пользователь/клиент может повторно отправить запрос. Дополнительные сведения о коде ошибки 408 Request Timeout см. в RFC7231, раздел 6.5.7  9.0003

 

409: Конфликт

Код статуса ошибки 409 Конфликт указывает, что запрос от клиента не может быть обработан из-за конфликта с сервером. Запрос от клиента прошел нормально, но на стороне сервера возникли проблемы, из-за которых запрос не мог быть выполнен. Примером этого может быть запрос на редактирование, удаление или создание определенного файла пользователем, но эти функции не разрешены. Наряду с 409ответ, сервер должен вернуть инструкции о том, как пользователь может решить эту проблему, или указать, почему проблема возникает. Дополнительную информацию см. в RFC7231, раздел 6.5.8.

 

410: Исчез

Как и код ошибки 404 Not Found, который мы рассмотрели ранее, код состояния 410 Gone указывает на то, что ресурс, который запрашивает клиент, удален и больше недоступен с сервера. Никакой дополнительной информации о перенаправлении URL или о том, где получить доступ к ресурсу, не предоставляется. Оно было удалено на неопределенный срок. Дополнительные сведения о коде ошибки 410 Gone см. в RFC7231, раздел 6.5.9.

 

411: Требуемая длина

Код статуса ошибки 411 Требуемая длина указывает, что сервер не разрешает запрос от клиента из-за предопределенной длины содержимого тела запроса. Клиент может повторить запрос, если в последующем запросе ресурса указан действительный заголовок Content-Length. Дополнительные сведения о коде ошибки 411 Length Required см. в RFC7231, раздел 6.5.10  

 

412: Precondition Failed

Условные запросы к серверу разрешены как часть протокола HTTP. Если в запросе соблюдены правильные условия, запрос выполняется и обрабатывается сервером. Код ошибки 412 Precondition Failed означает, что одно или несколько условий в заголовке запроса не выполнены. Например, это можно использовать в запросах GET, а условный запрос используется для возврата ресурса только в том случае, если этот ресурс изменился. Дополнительные сведения о коде ошибки 412 Precondition Failed см. в RFC7232, раздел 4.2   9.0003

 

413: Объект запроса слишком велик

Код статуса ошибки 413 Объект запроса слишком велик указывает на то, что сервер не примет и не обработает запрос из-за того, что размер тела запроса больше, чем сервер может разрешить или обработать. К таким примерам относится загрузка файла, когда файл превышает максимальный размер загрузки, установленный сервером, или когда превышено максимальное количество загрузок. В случаях, когда возникает ошибка 413 Request Entity Too Large , сервер может полностью закрыть соединение, чтобы клиент не мог продолжить отправку запроса. В некоторых случаях вполне вероятно, что сервер разрешит клиенту повторить запрос, если это временное условие, и должен вернуть это сообщение клиенту. Однако возможно, что запрос может привести к тому, что на самом сервере закончится свободное место на физическом диске. В этом случае ошибка 507 Insufficient Storage — это ответ, который должен получить клиент. Дополнительную информацию см. в RFC7231, раздел 6.5.11.

 

414: URI Too Long

Не очень распространенный ответ сервера, код ошибки 414 URI Too Long означает, что сервер отклонил запрос клиента из-за того, что URL-адрес длиннее, чем сервер может обработать. Браузеры и поисковые системы устанавливают ограничения на длину URL-адресов, отчасти во избежание DDoS-атак или ошибок кода, но путь URL-адреса или HTTP не имеет явных ограничений. Таким образом, если лимит превышает установленный сервером, возникает ошибка 414 URI Too Long. Дополнительные сведения о коде ошибки 414 URI Too Long см. в RFC7231, раздел 6.5.12   9.0003

 

415: Неподдерживаемый тип носителя

Код ошибки 415 Неподдерживаемый тип носителя указывает, что сервер не может обработать тело запроса или его часть из-за неподдерживаемого формата носителя. Даже если запрос от клиента поддерживается, ошибка 415 может возвращаться, если в теле запроса есть неподдерживаемый контент. Код ошибки 415 Unsupported Media Type похож на код состояния 406 Not Acceptable. Разница в том, что код ошибки 406 Not Acceptable возникает не из-за содержимого заголовка или кодировки, а из-за значения, установленного в заголовке HTTP. Убедитесь, что сервер может обрабатывать определенный формат, а также отправив запрос в правильной форме, чтобы избежать появления кода ошибки 415 Unsupported Media Type. Дополнительную информацию см. в RFC7231, раздел 6.5.13.

 

416: диапазон неудовлетворителен

Как указано в коде состояния 206 Partial Request, клиенты/браузеры могут запросить частичный ответ с сервера, будь то определенная часть файла или видео например. Клиенты и серверы используют так называемые запросы диапазона для выполнения этих запросов. Однако, если сервер не поддерживает такие типы запросов, он просто вернет весь ресурс вместе с ответом 200 ОК. Если сервер поддерживает запросы диапазона, именно здесь появляется код ошибки 416 Partial Request, который возвращает то, что запрашивает клиент. В ситуации, когда сервер поддерживает запросы диапазона, но сервер не согласен с полученным запросом, поскольку он не попадает в диапазон или, возможно, выходит за пределы указанного диапазона, будет возвращен код ошибки 416 Range Not Satisfiable. Дополнительную информацию см. в RFC7233, раздел 4.4.

 

417: Ожидание не выполнено  

Клиенты могут использовать заголовок Ожидание , чтобы указать, что они ожидают определенного поведения от сервера. Как описано в коде состояния 100 Continue, клиенты могут проверить сервер, примет ли он запрос. Если это так, сервер ответит кодом состояния 100 Continue. В противном случае код ошибки 417 Expectation Failed указывает на то, что сервер не понял заголовок Expect или не поддерживает его, поэтому он не может обработать запрос клиента. Дополнительную информацию о коде ошибки 417 Expectation Failed см. в RFC7231, раздел 6.5.14   9.0003

 

418-42 0 : Не назначено

Коды состояния ошибки 418–421 в настоящее время не назначены, однако в некоторых случаях используется код состояния 418 I’m a Little Teapot. Созданный как первоапрельская шутка, он приобрел некоторую популярность и иногда используется как шутка или пасхальное яйцо, а не для реальных повседневных целей. Большинство браузеров игнорируют его, так как это не официальный код состояния. Другим в этой категории является код ошибки 420 Enhance Your Calm, который был представлен Twitter. Это код ошибки, который сообщает клиентам, что у них ограничена скорость, то есть ограничение на количество запросов, которые они могут сделать в течение определенного периода времени. С 1989, редактор RFC будет публиковать более юмористические RFC. В Википедии есть полное изложение более юмористических первоапрельских RFC.

 

421: Misdirected Request  

Представленный в протоколе HTTP/2 код ошибки 421 Misdirected Request означает, что сервер получил запрос, который не предназначался для этого конкретного сервера, и не может должным образом ответить. Это может произойти, если DNS (система доменных имен) настроена на неправильный IP-адрес. Клиенты должны включить  Host Заголовок в запросе. Это также может произойти с сайтами, имеющими один SSL-сертификат из нескольких доменов. Это может быть вызвано проблемой с хостинг-провайдером и/или конкретным используемым браузером, поэтому может потребоваться много работы, чтобы действительно понять, в чем проблема. Если сервер знает, что домен не настроен для запроса, он ответит сообщением об ошибке 421 Misdirected Request. Дополнительную информацию см. в RFC7540, раздел 9.1.2.

 

422:  Unprocessable  Entity

Код ошибки 422 Unprocessable Entity указывает на проблему с содержимым синтаксиса запроса. Структура запроса была понята сервером, но поля в запросе недействительны или не соответствуют ожиданиям сервера. Как и коды статуса 102 Processing и 207 Multi-Status, код ошибки 422 Unprocessable Entity является частью протокола WebDAV и часто используется с веб-сервисами/API. Как правило, рекомендуемым ответом является 400 Bad Request, но если поддерживается WebDAV, следует использовать 422 Unprocessable Entity . См. RFC49.18, раздел 11.2 для получения дополнительной информации.

 

423: Заблокировано

Как и код состояния ошибки 422 Unprocessable Entity, код состояния ошибки 423 Locked также является частью протокола WebDAV. Код состояния 423 Locked указывает на то, что файл, ресурс или непосредственно, например, нельзя редактировать. Его цель — избежать одновременного обновления файла, ресурса и т. д. несколькими пользователями. При необходимости эти ресурсы можно разблокировать для редактирования. Дополнительную информацию о коде ошибки 423 Locked см. в документе RFC49.18, Раздел 11.3

 

424: Failed Dependency  

Другой код состояния, поддерживаемый протоколом WebDav; код ошибки 424 Failed Dependency указывает на то, что запрос от клиента не выполнен из-за зависимости от другого запроса, который также завершился неудачно. WebDAV использует метод, известный как PROPPATCH , для обновления определенных свойств ресурсов. Чтобы указать, успешно ли обновлен ресурс, WebDAV использует стандартные ответы с кодом состояния HTTP. Кроме того, код состояния 424 Failed Dependency используется только в том случае, если ответ в теле HTTP имеет ответ 207 Multi-Status. Итак, если PROPPATCH  используется, и ресурс не удается обновить, он отправит код состояния 4xx, указывающий на наличие ошибки при обновлении ресурса, также будет отправлен код ошибки 424 Failed Dependency вместе с другими запросами, которые зависели от успешного обновления, но не удалось. Дополнительную информацию см. в RFC4918, раздел 11.4.

 

425: Too Early

Код состояния HTTP 425 Too Early не используется в настоящее время. Он используется в ситуациях, когда HTTP-клиент подключается к HTTPS-клиенту. В процессе может потребоваться много времени для установления соединения между сервером и клиентом. Этот процесс может создать проблему безопасности, поэтому сервер предложит клиенту повторить запрос, пока не будет установлено защищенное соединение TLS (Transport Layer Security). В этом случае будет возвращен код состояния 425 Too Early. Дополнительные сведения о коде ошибки 425 Too Early см. в RFC8470, раздел 5.2  9.0003

 

426: Требуется обновление  

Код ошибки 426 Требуется обновление указывает клиенту, что ему необходимо использовать более новый протокол для отправки запросов на сервер. Например, клиент может использовать более старую версию HTTP, например HTTP/1.0, но серверу требуется HTTP2.0. Сервер не примет запрос, но ответит клиенту, указав, какой протокол или протоколы являются приемлемыми. После того как клиент обновится до необходимого протокола (протоколов), сервер будет принимать запросы от клиента. Дополнительную информацию о коде ошибки 426 Upgrade Required см. в RFC7231, раздел 6.5.15 

 

427: Не назначено

Код состояния ошибки 427 в настоящее время не назначен.

 

428: Precondition Required  

Код ошибки 428 Precondition Required указывает клиенту, что запрос к серверу должен быть условным запросом. Как указано в коде состояния 304 Not Modified, клиент может отправить серверу условный запрос, например If-Match , If-None-Match , If-Modified-Since , If-Unmodified-Since или If-Range . Однако эти условные запросы не обязательны. Если они требуются серверу, сервер указывает на это, отвечая кодом ошибки 428 Precondition Required. Это немного похоже на код ошибки 412 Precondition Failed, но код ошибки 412 Precondition Failed возвращается, только если клиент включил в заголовок условный запрос, который не соответствует состоянию ресурса на стороне сервера. Уведомляя пользователей о том, что запросы должны быть условными, это гарантирует, что пользователи работают с нужными файлами или ресурсами, и помогает предотвратить возможную перезапись изменений пользователями. Дополнительную информацию см. в RFC6585, раздел 3 .

 

429: Too Many Requests  

Как видно из названия кода ошибки, код состояния ошибки 429 Too Many Requests означает, что реализовано ограничение скорости и что клиент превысил лимит количества запросов это может быть выполнено за указанное время. Наряду с ответом об ошибке 429 Too Many Requests должно быть указано, сколько времени ждать, прежде чем инициировать новый запрос к серверу, но раньше это не требовалось. Дополнительные сведения о коде ошибки «Слишком много запросов» см. в RFC6585, раздел 4   9.0003

 

430: Не назначено

Код статуса ошибки 430 в настоящее время не назначен, однако одно время предлагалось использовать код ошибки 430 Would Block в протоколе HTTP/1.1. Намерение состояло в том, чтобы служить ответом на так называемую конвейерную обработку. Это позволяло клиентам отправлять несколько запросов через TCP-соединение, ожидая ответа от сервера. Официально он так и не стал стандартом, поскольку протокол HTTP был обновлен до HTTP/2.0, а поддержка конвейерной обработки так и не получила широкого распространения.

 

431 Заголовки запроса слишком велики  

Код состояния ошибки 431 Заголовки запроса слишком велики указывает на то, что клиент отправил запрос заголовка, который превышает допустимый предел. Различные веб-серверы имеют разные допустимые ограничения размера заголовков. Это может быть связано с тем, что отдельный запрос заголовка слишком велик, или из-за общего размера всех запросов заголовков. В большинстве случаев это можно легко исправить, так как обычно это вызвано отправкой слишком большого количества файлов cookie или файлов cookie слишком большого размера. Дополнительные сведения о коде ошибки 431 Request Headers Too Large см. в RFC6585, раздел 5    9.0003

 

432-450 Не назначено

Коды состояния ошибки с 432 по 450 в настоящее время не назначены.

 

451: Недоступно по юридическим причинам  

Код состояния ошибки 451 Недоступно по юридическим причинам указывает, что сервер отказывается обслуживать запрошенный контент по юридическим причинам, а также должен указывать причину ошибки. в ответ пользователю. Причинами использования кода ошибки 451 «Недоступно по юридическим причинам» могут быть правительства, которые подвергают цензуре определенный контент, контент, нарушающий законы об авторских правах, например DMCA (Законы об авторском праве в цифровую эпоху), или контент, который нарушает законы или постановления суда. Коды статуса ошибки 403 Forbidden и 404 Not Found иногда используются вместо кода статуса ошибки 451, но код статуса ошибки 451 предоставляет больше информации или пояснений, почему возникает ошибка. Пользователи обычно обходили ошибку 451, внедряя VPN для доступа к контенту. Дополнительную информацию см. в RFC7725, раздел 3 .

  

452-499: Не назначено

Коды ошибок 452-499 в настоящее время не назначены.

 

5xx: Ошибка сервера  

Как и коды состояния 4xx, коды состояния 5xx указывают на наличие ошибки, однако данная ошибка маловероятна из-за плохого соединения или самого браузера. Коды состояния 5xx указывают на проблему на уровне сервера и не могут обработать запрос от клиента. Наряду с ошибкой сервер должен ответить с объяснением ошибки, является ли это временным или постоянным состоянием, и как его можно исправить.

 

500: Внутренняя ошибка сервера

Код состояния 500 Внутренняя ошибка сервера просто означает, что сервер обнаружил проблему и не может обработать запрос. Как правило, код 500 Internal Server Error используется скорее как общий код ошибки сервера, если конкретная проблема не подпадает ни под одну из других спецификаций кода состояния 5xx Server Error. Код 500 Internal Server Error, вероятно, является наиболее часто используемым из кодов классификации 5xx Server Error. Дополнительную информацию см. в RFC7231, раздел 6.6.

 

501 : Не реализовано

Коды состояния ошибки 501 Не реализовано возникают, когда сервер не распознает метод запроса и, следовательно, не может поддерживать или обрабатывать запрос. Это похоже на код статуса ошибки клиента 405 Method Not Allowed, но код статуса ошибки 501 Not Implemented может указывать на то, что метод запроса от клиента действителен, но не поддерживается сервером. Статус ошибки 405 Method Not Allowed указывает на то, что метод, вызванный клиентом, не поддерживается и не должен использоваться. Дополнительную информацию см. в RFC7231, раздел 6.6.2.

 

502 Bad Gateway

Код состояния ошибки 502 Bad Gateway означает, что сервер действует как прокси-сервер и получил ответ от исходного сервера, который был признан недействительным. Возможно, это связано с перегрузкой сервера, и клиент может повторно отправить запрос, но в большинстве случаев это происходит из-за проблемы с веб-сервером или сетью доставки контента (CDN), расположенной между клиентом и сервером, и может потребоваться дополнительная устранение неполадок с хостинг-провайдером, чтобы понять, почему возникает ошибка. Дополнительную информацию см. в RFC7231, раздел 6.6.3.

 

503 :  Сервис недоступен. доступ недоступен, и сервер не может выполнить запрос из-за текущего состояния. Клиенты иногда видят сообщение вместе с кодом ошибки 503 "Сервис недоступен", в котором им предлагается повторить запрос позже. Однако он может не дать точного объяснения того, когда и как долго может длиться код ошибки 503 Service Unreachable. Дополнительную информацию см. в RFC7231, раздел 6.6.4.

 

504: Время ожидания шлюза

Как и код ошибки 502 Bad Gateway, код ошибки 504 Gateway Timeout используется, когда сервер действует как прокси-сервер, но ответит кодом ошибки 504 Gateway Timeout, если ответ исходного сервера занимает слишком много времени. Код состояния ошибки 502 Bad Gateway следует использовать в тех случаях, когда ответ недействителен или вообще не получен прокси-сервером. Сообщение вместе с тайм-аутом шлюза 504 может указывать и рекомендовать клиенту повторить попытку отправки запроса. Дополнительную информацию см. в RFC7231, раздел 6.6.5.

 

505: Версия HTTP не поддерживается

Код ошибки 505 Версия HTTP не поддерживается означает, что сервер не поддерживает версию протокола HTTP, используемого в сообщении запроса, и, следовательно, не может обработать запрос. Наряду с кодом ошибки 505 Версия HTTP не поддерживается, ответ сервера должен включать сообщение, указывающее, почему этот конкретный протокол HTTP не поддерживается и какие протоколы поддерживаются. Дополнительную информацию см. в RFC7231, раздел 6.6.6.

 

506: вариант, также согласовывается

Вариант 506, также согласовывается — это экспериментальный код статуса HTTP, который на сегодняшний день не является частью стандарта. Вариант 506 также согласовывает указывает на внутреннюю проблему конфигурации сервера из-за проблем с согласованием контента. Согласование содержимого позволяет клиентам отправлять несколько заголовков accept и сообщает серверу, какое конкретное представление ресурса следует использовать, как указано в браузере. Это может быть связано с предоставлением нужного языка, формата документа и т. д. Несмотря на то, что код состояния ошибки 506 Variant Also Negotiates находится в экспериментальном статусе и официально не является частью стандарта HTTP, он используется в редких случаях. Некоторые пользователи Google Play сталкивались с этой проблемой в прошлом при попытке загрузить несколько версий приложения, из-за чего их устройства постоянно пытались загрузить приложение в замкнутом цикле. См. RFC229.5, раздел 8.1 для получения дополнительной информации.

   

507: Недостаточно памяти

A 507 Недостаточно памяти Код состояния ошибки сервера также является частью протокола WebDAV. Код ошибки 507 Insufficient Storage указывает клиенту, что запрос, например PUT или POST , имеет слишком большой размер файла. Это также может указывать на то, что на сервере временно закончилось свободное пространство. Дополнительную информацию см. в RFC4981, раздел 11.5.

 

508: Loop Detected

Код состояния ошибки сервера 508 Loop Detected, как и код ошибки сервера 507 Insufficient Storage, является частью протокола WebDAV. В рамках протокола WebDAV клиент может сделать запрос на сервер для всего каталога и создать цель где-то в том же каталоге, что приведет к бесконечному циклу запросов и ответов. Код состояния ошибки сервера 508 Loop Detected указывает на то, что сервер завершил запрос клиента, в частности 9.1777 Глубина: В f inity , потому что сервер идентифицировал запрос как результат бесконечного цикла, неоднократно вызывая сам себя. Дополнительную информацию см. в RFC5842, раздел 7.2.

 

509: Не назначено

Код состояния ошибки сервера 509 в настоящее время не назначен.

 

510: не расширен

Код состояния ошибки сервера 510 Not Extended в настоящее время находится в предложенном/экспериментальном статусе и не является частью стандартной спецификации кодов состояния HTTP. 510 Not Extended указывает клиенту, что для запроса требуется расширенный HTTP-запрос. Если сервер отвечает кодом ошибки сервера 510 Not Extended, в нем также должно быть указано, как клиент должен исправить свой запрос, но в спецификации это прямо не указано. Ведутся споры о том, следует ли подпадать под классификацию ошибок сервера 5xx, поскольку ее можно рассматривать как ошибку клиента 4xx, но поскольку она формально не является частью стандарта, она не актуальна и редко используется в повседневном использовании. Дополнительную информацию см. в RFC2774, раздел 7.

 

511: Требуется авторизация в сети

Код состояния ошибки сервера 511 Требуется авторизация в сети, который требует, чтобы клиент аутентифицировал себя, чтобы получить доступ к сети. Например, пользователи могут увидеть это при попытке подключиться к общедоступной сети Wi-Fi в компании, и пользователи должны согласиться с их условиями, прежде чем им будет предоставлен доступ. Наряду с ответом об ошибке сервера 511 Network Authorization Required пользователи также должны быть перенаправлены туда, где они могут войти в систему. Дополнительную информацию см. в RFC6585, раздел 6.

 

512-599: Не назначено

Коды состояния ошибки сервера 512-599 в настоящее время не назначены, но некоторые компании могут использовать любой из них в качестве настраиваемых сообщений об ошибках сервера для клиентов.

 

Мониторинг Код состояния HTTP  Ответы  

Чтобы лично просмотреть список кодов состояния для определенного URL-адреса, перейдите на вкладку инструментов разработчика в браузере. Наряду с показателями скорости загрузки страницы вы также можете просматривать любые ответы сервера вместе со всеми связанными кодами состояния HTTP, чтобы убедиться, что все на вашей странице загружается и отображается правильно.

Для более активного и автоматизированного подхода к мониторингу профессиональные решения для мониторинга от Dotcom-Monitor могут гарантировать, что всякий раз, когда пользователь сталкивается с определенным кодом ошибки HTTP, ваши команды будут немедленно уведомлены, чтобы они могли быстро устранить проблему. Вы также можете использовать функцию "Фильтры", чтобы удалить отдельные коды состояния HTTP из задач, предупреждений и отчетов, чтобы игнорировать любые коды состояния HTTP, которые не относятся к вашим конкретным потребностям.

 

Что означают эти коды состояния HTTP?

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

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

Как взаимодействуют веб-клиенты и серверы

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

В своем ответе веб-сервер включает не только содержимое. Во-первых, он включает в себя ряд заголовков, небольших фрагментов метаданных, которые относятся к ответу. Например, Заголовок Content-Type может выглядеть так:

 Content-Type: text/html; кодировка = UTF-8 

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

Но перед содержимым, даже перед заголовками, каждый ответ HTTP включает строку, которая выглядит примерно так:

 HTTP/1.1 200 ОК 

В этом примере наряду с версией HTTP (1. 1) код состояния читается как «200 OK». Другими словами, «все хорошо, вот ваш контент». 200 - самый важный бит. Системы могут протестировать его, чтобы точно определить, что произошло. «ОК» — это хорошая короткая подсказка, описывающая статус для всех, кто смотрит.

Коды состояния 404 и 200 очень распространены, но существует гораздо больше возможностей.

  • 500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА) — это состояние ошибки. Это означает, что на сервере что-то пошло не так, и он не может выполнить запрос. Это может быть ошибка программирования или какая-либо другая ошибка времени выполнения.
  • 403 (ЗАПРЕЩЕНО) означает, что сервер понял запрос, но отказывается его разрешить. Это часто относится к действиям, связанным с пользователем, в более сложных веб-приложениях. Например, при попытке отредактировать пост, принадлежащий кому-то другому.
  • 401 (НЕАВТОРИЗОВАННЫЙ) очень похож на 403. В этом случае исходному запросу не разрешен доступ к ресурсу, поскольку он не предоставил никаких учетных данных пользователя. Другими словами, вы не вошли в систему.
  • 400 (ПЛОХОЙ ЗАПРОС) означает, что сервер не может понять, что запрашивается. Возможно, отсутствует какая-то информация, например параметр URL. Возможно, что-то испортило запрос при передаче.

Все коды состояния, которые мы видели до сих пор, состоят из трех цифр, все от 200 до 500. Это не совпадение. Все статусы HTTP состоят из трех цифр, первая цифра от одного до пяти включительно. И значение этой первой цифры помещает код в одну из пяти групп, каждая из которых имеет определенное значение.

Первая группа, 1xx, является «информационной». Все эти случаи означают, что сервер понял запрос, но не готов отправить ответ. Вы не увидите их в действии, но они есть для систем, которым они нужны.

Группа 2xx содержит ответ, который вам обычно нужен: 200 (ОК) . Это самый распространенный случай успеха, но есть и другие.

Код 204 (БЕЗ СОДЕРЖИМОГО) довольно странный. Сервер может вернуть его в результате PUT, POST или PATCH. Смысл в этих случаях будет заключаться в том, что сервер сделал обновление, но клиенту не нужно ничего возвращать.

Коды

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

Это может быть временным, например, в случае 302 (FOUND) , который сайт может использовать для размещения рекламного URL-адреса, который перенаправляет на страницу конечного продукта. Вместо этого сайт может использовать постоянную переадресацию через 301 (ПЕРЕМЕЩЕНО ПОСТОЯННО) статус. Это хорошая практика, когда, например, сайт изменил название страницы.

Статусы переадресации

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

Статусы, начинающиеся с 4, являются ошибками клиента. По сути, они означают, что «браузер (или человек, использующий его) сделал что-то не так». Мы уже обсуждали некоторые из них (400, 401, 403, 404), и это самая большая группа кодов состояния на значительное количество. Другие примеры ошибок клиента включают запрос URL-адреса, который раньше существовал, но больше не существует: 410 (УДАЛЕНО) . Также есть 429 (TOO MANY REQUESTS) , который поддерживает ограничение скорости, чтобы ресурсы не перегружались. Это очень часто используется REST API.

Наконец, статусы в диапазоне 500-599 указывают на то, что что-то пошло не так с сервером, когда он пытался выполнить запрос.

Наиболее часто используемым универсальным инструментом командной строки HTTP является curl . Используя curl, вы можете отправлять HTTP-запросы вручную, просматривать основные сведения об ответе и проверять коды состояния.

Программа curl не позволяет невероятно легко отображать только код состояния, но вы можете сделать это, используя несколько параметров, а именно:

  • -o <имя файла> указывает curl отправлять вывод по умолчанию в файл. Вы можете использовать его, чтобы отказаться от всего нормального вывода.
  • -w отображает пользовательскую информацию из набора доступных переменных, одной из которых является «http_code», т.е. код состояния ответа.

Вы также можете использовать -s , чтобы скрыть некоторые подробности, которые curl обычно показывает о передаче, например, ход выполнения в реальном времени. Вот как объединить эти параметры:

 $ curl -sw "%{http_code}" -o /dev/null http://example.org 
200
$ curl -sw "%{http_code}" -o /dev/null http://bbc.co .uk
301

Или вы можете использовать немного другие параметры и конвейер для обработки результата:

 $ curl -sI http://example. org/no | голова -1 | вырезать -f2 -d'' 
404

Если вам когда-нибудь понадобится проверить коды состояния HTTP, вам может помочь ваш веб-браузер. Большинство современных браузеров имеют консоль, которая может отображать расширенную информацию. Используя Chrome в качестве примера, вот как проверить код состояния URL:

  1. Выберите Вид -> Разработчик -> Инструменты разработчика в главном меню. Это переключает маленькое окно в нижней части браузера.
  2. Если вы еще не просматриваете вкладку Network в окне инструментов разработчика, перейдите на нее.
  3. Нажмите кнопку Doc , чтобы отобразить только запросы на содержание страницы.
  4. Обновите просматриваемую страницу.

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

Другие ресурсы

Существует множество хороших ресурсов, которые подробнее объясняют коды состояния HTTP. Страница Википедии под названием «Список кодов состояния HTTP» и этот официальный документ о стандартах отслеживания данных являются хорошими отправными точками.

Наиболее полезной ссылкой может быть httpstatuses.com. Он объясняет все коды состояния HTTP в кратком и простом для понимания формате. Он также дает полезные сведения о коде, которые могут пригодиться при программировании чего-либо, связанного с HTTP.

Особенно полезен формат URL-адресов httpstatuses. Страница для кода состояния 403 — это просто https://httpstatuses.com/403 . Вы можете легко изменить URL-адрес, чтобы найти любой код состояния, который вам нужен.

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

HTTP2 — это следующая версия HTTP, но хорошая новость заключается в том, что коды состояния остались прежними. Все, что вы здесь узнали, будет актуально в обозримом будущем.

Объяснение кодов состояния ответа HTTP

Минуты

Любой веб-сервер будет выдавать коды состояния HTTP в ответе на запрос клиента. В этом списке показаны коды из запроса комментариев IETF (RFC) и некоторые дополнительные часто используемые коды. Первая цифра кода состояния HTTP указывает один из пяти стандартных классов ответов.

1xx Информационный

Что делают коды статуса 1xx ? Они дают временный ответ. Но как они на самом деле работают? Коды состояния 1xx состоят из строки состояния и закрываются только пустой строкой, поэтому заголовки не нужны для этого типа кода состояния. Поскольку HTTP/1.0 вообще не дает определений для кодов состояния 1xx, крайне важно, чтобы серверы доставляли ответ 1xx клиенту HTTP/1.0 только в целях расследования, а не при каких-либо других обстоятельствах.

Клиент должен иметь возможность обрабатывать один или несколько ответов о статусе 1xx перед стандартным ответом, даже если этот клиент не ожидает получения сообщения 100 continue. Пользовательские агенты могут безопасно игнорировать ответы о статусе 1xx, если они не ожидают их.

Однако прокси-серверы должны пересылать ответы 1xx, если между прокси-сервером и клиентом нет закрытого соединения или прокси-сервер сам создал запрос на ответ 1xx. Например, если прокси должен добавить поле «ожидание: 11-продолжить» к переадресованному запросу, ему не потребуется пересылать соответствующий ответ 100 (продолжить) (или ответы).

100 Продолжить

Код состояния 100 Продолжить указывает, что серверу были отправлены заголовки запроса. Это также указывает на то, что соответствующий клиент может продолжать доставлять тело запроса. Это применимо, когда необходимо тело (например, запрос POST). Для больших тел запросов неэффективно доставлять их на сервер после того, как запрос был отклонен из-за неподходящих заголовков.

Вы можете попросить сервер узнать, будет ли принят запрос исключительно по его заголовкам — отправьте Expect: 100-continue как заголовок в начальном запросе. Он будет продолжен, если код был получен в ответ, или завершится, если он получит ответ 417 Expectation Failed.

101 Переключение протоколов

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

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

102 Обработка (WebDAV)

В качестве промежуточного ответа код 102 Обработка уведомляет клиента о том, что сервер принял запрос, но еще не выполнил его. Код обработки 102 обычно выдается только тогда, когда есть веские основания ожидать, что обработка займет довольно много времени. Серверы будут выдавать ответы 102 (Обработка), если выполнение запроса займет более 20 секунд. Затем они предоставят окончательный ответ после завершения запроса.

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

2xx Успех

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

200 OK

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

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

201 Created

Это означает, что запрос был выполнен и был создан новый ресурс, который можно идентифицировать с помощью URI, включенных в объект, к которому относится ответ, с наиболее конкретным URI для ресурса, заданным поле заголовка местоположения. Ответ должен включать сущность, содержащую список характеристик ресурсов и местоположений. Затем пользователь или пользовательский агент может использовать это, чтобы выбрать наиболее подходящий. Формат объекта определяется любым типом мультимедиа, представленным в поле заголовка Content-Type.
: Исходный сервер должен создать ресурс, прежде чем он сможет выдать код состояния 201 Created . Если действие невозможно выполнить сразу, вместо этого сервер должен выдать ответ 202 (что означает «Принято»). Поле заголовка ответа ETag может быть включено в ответ 201, чтобы показать, что текущее значение тега объекта для запрошенного варианта только что было создано.

202 Принят

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

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

203 Неавторизованная информация

Сервер успешно обработал запрос, хотя он возвращает информацию, которая может быть из другого источника. Не найдено в HTTP/1.0, но найдено в HTTP/1.1. Возвращенная метаинформация в заголовке объекта не является окончательным набором, который можно получить с исходного сервера. Вместо этого он был получен из локальной или сторонней копии. Представленный набор МОЖЕТ быть подмножеством или надмножеством исходного. Например, если он включает в себя локальную аннотационную информацию о ресурсе, это может привести к расширению метаинформации, доступной для исходного сервера. Использование этого кода ответа не является обязательным и будет уместным только в том случае, если в противном случае ответ был бы 200 (ОК).

204 Нет содержимого

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

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

205 Сбросить содержимое

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

206 Partial Content

Сервер завершил обработку частичного запроса GET для ресурса. Этот запрос должен включать поле заголовка Range (раздел 14.35), которое указывает предпочтительный диапазон, и ему разрешено включать поле заголовка If-Range (раздел 14.27), чтобы запрос был сделан условным. Следующие поля заголовка должны быть включены в ответ:

  • Либо поле заголовка Content-Range (раздел 14. 16), указывающее диапазон, включенный в этот ответ, либо тип содержимого multipart/byteranges, включающий поля Content-Range для каждой части. Если в ответе присутствует поле заголовка Content-Length, его значение должно соответствовать фактическому количеству OCTET, переданных в теле сообщения.
  • Дата
  • ETag и/или Content-Location, если заголовок был бы отправлен в ответе 200 на тот же запрос
  • Expires, Cache-Control и/или Vary, если значение поля может отличаться от значения, отправленного в любом предыдущем ответе для того же варианта

Если запрос If-Range, в котором использовался надежный валидатор кеша, вызвал ответ 206, то он не должен содержать никаких других заголовков сущностей. Если это был результат запроса If-Range, в котором использовался слабый валидатор, ответ не должен включать другие заголовки сущностей; идея этого состоит в том, чтобы предотвратить несоответствия между обновленными заголовками и кэшированными телами сущностей. В других случаях ответ должен содержать все заголовки объектов, которые были бы возвращены с ответом 200 (ОК) на идентичный запрос. Кэш не должен объединять ответ 206 с другим ранее кэшированным содержимым, если заголовки ETag или Last-Modified не совпадают точно (см. 13.5.4). Кэш, который не поддерживает заголовки Content-Range и Range, не должен кэшировать ответы 206 (Partial).

207 Multi-Status (WebDAV)

Предоставляет информацию о состоянии для многочисленных независимых операций. (Раздел 11 содержит дополнительную информацию об этом).

208 Уже передано (WebDAV)

Этот код можно использовать в элементе ответа DAV: propstat, чтобы избежать повторной нумерации внутренних элементов нескольких привязок к одной и той же коллекции. Для каждой привязки к коллекции, которая попадает в область запроса, только одна сообщается со статусом 200, в то время как последующие элементы ответа DAV: для всех дополнительных привязок используют статус 208, и никакие элементы ответа DAV: для их потомков не будут включены.

Участники в привязке DAV будут подсчитаны в ответе до этого запроса и не будут включены снова.

226 IM Used

Сервер выполнил запрос GET для ресурса и ответил представлением результата одной или нескольких манипуляций с экземпляром, примененных к текущему экземпляру. Текущий экземпляр может быть недоступен, за исключением комбинации этого ответа с другими предшествующими или предстоящими ответами, что может применяться для конкретных манипуляций с экземпляром. В этом случае заголовки результирующего экземпляра получаются из комбинации заголовков ответа status-226 и других экземпляров, как это предусмотрено правилами раздела 13.5.3 спецификации HTTP/1.1.
: Запрос должен включать поле заголовка A-IM, в котором указано как минимум одно манипулирование экземпляром. Ответ должен включать поле заголовка Etag, представляющее тег сущности настоящего экземпляра.
Ответ, полученный с кодом состояния 226, МОЖЕТ быть помещен в кэш и развернут при ответе на последующий запрос, в зависимости от механизма истечения срока действия HTTP и любых заголовков Cache-Control, а также требований, содержащихся в разделе 10. 6. Ответ, полученный с кодом состояния 226, МОЖЕТ использоваться кэшем в сочетании с записью кэша для базового экземпляра для создания записи кэша для текущего экземпляра.

3xx Redirection

Код состояния 3xx Redirection показывает, что пользовательский агент должен предпринять дальнейшие действия, прежде чем запрос будет выполнен. Пользовательский агент может автоматически выполнить необходимое действие при условии, что во втором запросе используется метод HEAD или GET. Клиент должен будет идентифицировать бесконечные петли перенаправления, поскольку они могут привести к двунаправленному трафику. В прошлом максимальное количество перенаправлений, рекомендованное спецификацией, составляло пять. Важно при разработке контента помнить, что могут быть клиенты, использующие этот лимит.

300 Множественный выбор

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

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

Правильный выбор возможен автоматически, хотя это зависит от формата и возможностей пользовательского агента. Тем не менее, эта спецификация не устанавливает стандарт для этой формы автоматического выбора: когда у серверов есть предпочтительный вариант представления, они должны добавить соответствующий URL-адрес в поле «Местоположение». Пользовательские агенты могут использовать значение поля Location для автоматического перенаправления, и этот ответ может кэшироваться, если это разрешено.

301 Перемещено навсегда

Код состояния 301 Moved Permanently показывает, что запрошенному ресурсу был предоставлен новый постоянный URL-адрес, и все ссылки на него в будущем должны использовать один из возвращенных URL-адресов. Если клиенты могут редактировать ссылки, они должны автоматически повторно связывать ссылки Request-URL по крайней мере с одной из тех новых ссылок, которые указал сервер. В некоторых случаях этот ответ можно кэшировать.

В ответе новый постоянный URL должен быть добавлен в поле Местоположение. Объект запроса должен включать краткую гипертекстовую примечание для ссылки на последний URL-адрес, если только не использовался метод запроса HEAD. Если код 301 генерируется каким-либо ответом, кроме запроса HEAD или GET, пользовательский агент не должен автоматически перенаправлять запрос, за исключением случаев, когда соответствующий пользователь может его проверить. В противном случае это может изменить условия, ведущие к выдаче запроса.

Однако, когда запрос POST автоматически перенаправляется после получения кода состояния 301, некоторые пользовательские агенты HTTP/1.0 случайно переключат его на запрос GET.

302 Найдено

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

Временный URL-адрес должен быть указан в поле Location в ответе. За исключением случаев, когда использовался метод запроса HEAD, объект ответа должен содержать краткую гипертекстовую заметку, содержащую гиперссылку на последний URL-адрес. В некоторых случаях код 302 может быть доставлен после запроса, который не является ни HEAD, ни GET. Если это так, пользовательский агент не должен автоматически перенаправлять запрос, если пользователь не может его подтвердить. В противном случае могут быть изменены и условия, на которых был выдан запрос.

Имейте в виду, что в RFC 2068 и RFC 1945 клиенту не разрешено настраивать метод перенаправленного запроса, хотя большинство реализаций пользовательских агентов сегодня рассматривают код состояния 302 , как если бы это был ответ 303. Это означает, что они проигнорируют первоначальный метод запроса и выполнят GET для значения поля Location. Коды состояния 307 и 303 были реализованы для того, чтобы серверы могли точно определить, какой тип реакции они ожидают от клиента.

303 См. Другое

Запрос-ответ был сохранен в другом URI, и для его восстановления потребуется метод GET для этого ресурса. Основная причина использования этого метода заключается в том, чтобы позволить выходу сценария, активированного POST, отправить пользовательский агент на определенный ресурс. Новый URI не является резервной ссылкой для первоначально запрошенного ресурса. Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может кэшироваться.
В поле Location в ответе должен быть указан другой URI. За исключением случаев, когда метод запроса был HEAD, объект ответа должен содержать короткую гипертекстовую заметку с гиперссылкой на новый URI. Примечание. Многие пользовательские агенты до HTTP/1.1 не понимают статус 303. Когда необходимо работать с такими клиентами, вместо этого можно использовать код состояния 302, потому что большинство пользовательских агентов реагируют на ответ 302, как мы описываем здесь для 303.

304 Не изменен

Указывает, что ресурс не был изменен с момента последнего запроса. Если клиент выполнил условный запрос GET и доступ разрешен, но документ не был изменен, то сервер должен ответить этим кодом состояния. Ответ 304 Not Modified не должен содержать тело сообщения и поэтому всегда заканчивается первой пустой строкой после полей заголовка. Ответ должен содержать следующие поля в заголовке:

  • Дата, за исключением случаев, когда ее отсутствие требуется в соответствии с разделом 14. 18.1
  • Если исходный сервер без часов следует этим правилам, а прокси и клиенты добавляют свою дату к любому ответу, полученному без нее (как ранее определено в [ RFC 2068 ] , раздел 14.19), кеши будут работать корректно.
  • ETag и/или Content-Location, если заголовок был бы отправлен в ответе 200 на тот же запрос
  • Expires, Cache-Control и/или Vary, если значение поля отличается от отправленного в любом более ранний ответ для того же варианта.

Если условный GET использовал надежный валидатор кэша (см. раздел 13.3.3), ответ не должен включать другие заголовки объектов. В противном случае (например, когда условный GET использует слабый валидатор) ответ не должен включать другие заголовки сущностей; это предотвращает несоответствия между кэшированными телами сущностей и обновленными заголовками.
Если ответ 304 указывает на объект, который в данный момент не кэшируется, то кэш должен проигнорировать ответ и повторить запрос без условия. Если кеш использует полученный ответ 304 для обновления записи кеша, ему потребуется обновить запись, чтобы отразить любые новые значения полей, указанные в ответе.

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

Запрошенный ресурс должен быть доступен с использованием прокси поля локализации. Поле Location предоставляет URI прокси-сервера. Предполагается, что получатель повторит этот конкретный запрос, используя прокси. 305 Реакции должны производиться только исходными серверами. Примечание. Из RFC 2068 не было ясно, что 305 предназначался для перенаправления одного запроса и генерировался только исходными серверами. Несоблюдение таких ограничений имеет серьезные последствия для безопасности.

306 (не используется)

Код состояния 306 больше не используется и зарезервирован.

307 Временное перенаправление

Запрошенный ресурс временно находится под другим URI. Поскольку перенаправление может время от времени изменяться, клиент должен продолжать использовать Request-URI для будущих запросов. Этот ответ можно кэшировать, только если указано в поле заголовка Cache-Control или Expires. В ответе временный URI должен быть указан в поле Location. Объект ответа должен содержать короткую гипертекстовую заметку с гиперссылкой на новые URI, за исключением случаев, когда метод запроса был HEAD, потому что многие пользовательские агенты до HTTP/1.1 не понимают статус 307. Следовательно, примечание должно содержать необходимую информацию, чтобы пользователь мог повторить исходный запрос с новым URI. Если код состояния для 307 получен из-за запроса, отличного от GET или HEAD, пользовательский агент не должен автоматически перенаправлять запрос, за исключением случаев, когда он может быть подтвержден пользователем, поскольку это может изменить условия, при которых был отправлен запрос. .

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

308 Постоянная переадресация (экспериментальная)

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

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

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

400 Неверный запрос

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

401 Неавторизованный

То же, что 403 Запрещенный , но для использования, когда вполне возможно пройти аутентификацию, хотя это не сработало или еще не предлагалось. Запрос требует аутентификации пользователя. Ответ должен включать поле заголовка WWW-Authenticate (раздел 14.47), в котором содержится вызов, относящийся к запрашиваемому ресурсу. Клиент МОЖЕТ повторить запрос с соответствующим полем заголовка Authorization (раздел 14. 8). Если запрос уже включал учетные данные авторизации, то ответ 401 сообщает нам, что авторизация для этих учетных данных не была предоставлена. Если ответ 401 включает запрос, идентичный последнему ответу, и пользовательский агент уже пытался выполнить аутентификацию хотя бы один раз, то объект, указанный в ответе, должен быть предоставлен пользователю, поскольку этот объект может включать соответствующие диагностические данные. Аутентификация HTTP-доступа рассматривается в разделе «HTTP-аутентификация: базовая и дайджест-аутентификация доступа».

402 Требуется оплата

Этот код зарезервирован для использования в будущем. Первоначальное намерение состояло в том, чтобы этот код можно было использовать как часть программы электронных денег или микроплатежей, но этого результата не произошло, поэтому он не используется в обычном режиме. Однако служба MobileMe от Apple выдает пример ошибки 402 («httpStatusCode:402» в журнале консоли Mac OS X), если учетная запись MobileMe просрочена.

403 Запрещено

Сервер понял запрос, но отклоняет его. В отличие от ответа 401 Unauthorized, аутентификация не имеет значения, и запрос не должен повторяться. Если метод запроса не был HEAD, и сервер хочет сказать, почему запрос отклонен, необходимо указать причину, по которой объект сделал это. В качестве альтернативы можно использовать код состояния 404 (Не найдено), если сервер не хочет передавать эту информацию клиенту.

404 Не найдено

На сервере не найдено ничего, соответствующего Request-URI. Никаких указаний на то, является ли состояние постоянным или временным, не было дано. Код состояния 410 (Gone) необходимо использовать, когда сервер знает, что старый инструмент недоступен на неопределенный срок и не имеет адреса пересылки. Этот код состояния обычно используется, когда сервер не хочет раскрывать, почему именно запрос был отклонен, или когда другого ответа нет.

405 Метод не разрешен

Для Ресурса, описанного Request-URI, метод, указанный в Request-Line, не авторизован. Ответ ДОЛЖЕН включать заголовок Allow, который содержит список соответствующих методов для запрошенного ресурса.

406 Неприемлемо

За исключением случаев, когда это запрос HEAD, ответ должен содержать объект со списком доступных характеристик объекта и местоположения, из которых пользователь или пользовательский агент может выбрать наиболее подходящий. Формат объекта определяется типом носителя, представленным в поле заголовка Content-Type. От возможностей форматирования пользовательского агента зависит, сможет ли он автоматически выбрать наиболее подходящий вариант. Имейте в виду, что спецификация не описывает никаких стандартов для такого рода автоматического выбора.
Примечание. Серверы HTTP/1.1 могут возвращать ответы, неприемлемые в соответствии с заголовками Accept, отправленными в запросе. Иногда это может быть даже предпочтительным выбором для отправки ответа 406. Было бы полезно, если бы пользовательские агенты могли обращать внимание на заголовки входящих запросов, чтобы проверить, являются ли они приемлемыми или нет.

407 Proxy Authentication Required

Этот код чем-то похож на 401 Unauthorized , но он сообщает нам, что клиент должен сначала подтвердить себя с помощью прокси. Прокси-сервер должен будет вернуть поле заголовка Proxy-Authenticate (раздел 14.33) с запросом, который применяется к прокси-серверу для запрошенного ресурса. Клиент может повторить запрос с соответствующим полем заголовка Proxy-Authorization (раздел 14.34). Объяснение аутентификации доступа HTTP можно найти в разделе «Аутентификация HTTP: базовая и дайджест-аутентификация доступа».

408 Время ожидания запроса

Время ожидания запроса истекло. Спецификации HTTP W3 гласят: «Клиент не отправил запрос в течение времени, которое сервер был готов ждать. Клиент МОЖЕТ повторить запрос без изменений в любое время позже».

409 Конфликт

Приложение не может быть выполнено из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь разрешит конфликт и снова отправит запрос. Тело ответа должно содержать достаточную информацию, позволяющую пользователю определить, откуда возник конфликт. Идеальной ситуацией было бы, если бы объект ответа предоставил достаточную информацию о проблеме, чтобы позволить пользователю или пользовательскому агенту решить ее; хотя это может быть неосуществимо или даже необходимо. Ответ на запросы PUT является наиболее распространенной причиной проблем. Например, когда используется управление версиями и размещаемая вещь включает в себя изменения в ресурсе, который конфликтует с ресурсами, созданными по предыдущему (стороннему) запросу, сервер может использовать ошибку 409.ответ, указывающий на его неспособность предпринять это. Когда это произойдет, у отвечающего объекта, вероятно, будет список различий между отдельными версиями в формате, который определяет ответ Content-Type.

410 Gone

Запрошенный ресурс не может быть найден, адрес пересылки неизвестен и вряд ли будет найден. Если вы можете редактировать ссылки, вам следует удалить любые ссылки на этот ресурс. Используйте 404 [Not Found], если сервер не знает или не может узнать, является ли это постоянной ситуацией. Этот ответ может быть обналичен, если не указано иное.
: Основная цель ответа 410 – помощь в обслуживании сети. Он делает это, сообщая получателю, что ресурс намеренно недоступен и что владельцы сервера хотят, чтобы все удаленные ссылки на него были отключены. Это обычно происходит с краткосрочными рекламными услугами и ресурсами, а также с ресурсами, связанными с людьми, которые могли работать с сервером, но больше не участвуют в нем. Вам не нужно помечать каждый постоянно недоступный ресурс как «исчезнувший» или делать это бесконечно. Это полностью зависит от владельца сервера.

411 Требуется длина

Серверу требуется определенная длина содержимого, прежде чем он примет запрос. Клиент может сделать запрос еще раз, если он включает допустимое поле заголовка Content-Length, которое определяет в сообщении запроса длину тела сообщения.

412 Precondition Failed

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

413 Объект запроса слишком велик

Сервер отказывается обрабатывать запрос, поскольку запрос больше, чем сервер хочет или может обработать. Сервер МОЖЕТ закрыть соединение, чтобы клиент не мог продолжить запрос. Если условие является временным, сервер должен включить поле заголовка Retry-After, чтобы указать, что оно является временным, и через какое время клиент МОЖЕТ повторить попытку.

414 Request-URI Too Long

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

415 Неподдерживаемый тип носителя

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

416 Requested Range Not Satisfiable

Если запрос включает поле заголовка запроса Range (раздел 14.35), и ни одно из значений спецификатора диапазона в этом поле не перекрывает текущий экстент выбранного ресурса, а запрос не t включать поле заголовка запроса If-Range, тогда сервер должен ответить этим кодом состояния. (Для диапазонов байтов это означает, что первая байтовая позиция всех значений спецификации байтового диапазона превышает текущую длину выбранного ресурса.) Когда запрос диапазона байтов приводит к возврату этого кода состояния , поле заголовка объекта Content-Range, определяющее текущую длину выбранного ресурса (см. раздел 14.16), должно включать это в ответ. Этот ответ не должен использовать тип содержимого multipart/byte ranges.

417 Ожидание не выполнено

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

418 Я чайник (RFC 2324)

На самом деле, первоапрельская шутка IETF, которая была определена в 1998 году. но, естественно, это не остановило людей от попыток. HTTP-сервер Nginx использовал этот код для имитации поведения, похожего на goto.

420 Enhance Your Calm (Twitter)

API поиска и трендов Twitter возвращает это, когда скорость клиента ограничена. Это цитата из фильма «Разрушитель», а «420», вероятно, является намеком на то, что число связано с марихуаной. Другие службы могут предпочесть использовать в качестве альтернативы код ответа 429 Too Many Requests.

422 Unprocessable Entity (WebDAV)

Этот код состояния указывает, что сервер знает, какой тип контента запрашивается (именно поэтому код состояния 415 (неподдерживаемый тип мультимедиа) будет неверным), и синтаксис объекта запроса правильно (что также означает, что код состояния 400 (Bad Request) был бы столь же неуместным), но по какой-то причине он все еще не смог обработать инструкции, содержащиеся в запросе. Это состояние ошибки может иногда возникать, когда в теле запроса XML есть инструкции с правильным синтаксисом, но они содержат семантические ошибки.

423 Заблокировано (WebDAV)

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

424 Failed Dependency (WebDAV)

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

425 Зарезервировано для WebDAV

Слейн Дж., Уайтхед Э.Дж. и др., «Протокол расширенных коллекций WebDAV», в разработке.

426 Требуется обновление

Четкое указание на сбой необходимо для согласования надежных, функционально совместимых функций обновления. Код состояния 426 (требуется обновление) позволяет серверу четко указать точные расширения протокола, с которыми должен обслуживаться данный ресурс. Клиент должен перейти на альтернативный протокол, такой как TLS/1.0.

428 Требуется предварительное условие

Код состояния 428 показывает, что серверу-источнику необходимо, чтобы запрос был условным. Обычно это используется, чтобы избежать проблемы «потерянных обновлений», когда клиент ПОЛУЧАЕТ состояние ресурса, настраивает его и отправляет обратно на сервер, и пока это происходит, третья сторона изменила состояние на сервере, что естественно порождает конфликт. Настаивая на том, что запросы должны быть условными, сервер может гарантировать, что клиенты используют правильные копии. Ответы, в которых используется этот код, должны объяснять, как успешно отправить его повторно. 428 — это необязательный код состояния, который означает, что клиенты не должны полагаться на него для обхода конфликтов «потерянных обновлений».

429 Слишком много запросов

Код состояния 429 говорит о том, что пользователь отправил слишком много запросов в течение заданного периода («ограничение скорости»).
Представления ответа должны включать детали, объясняющие условие, и МОГУТ включать заголовок Retry-After, который показывает, как долго ждать, прежде чем можно будет сделать новый запрос.
Когда сервер подвергается атаке (или просто бомбардировке) запросами из одного источника, ответ на каждый с ошибкой 429 потребует слишком много ценных ресурсов. Следовательно, серверам не нужно использовать код состояния 429.. При ограничении использования ресурсов может быть лучше что-то столь же простое и эффективное, как разрыв соединений.

431 Поля заголовка запроса слишком велики

Этот код говорит о том, что сервер не хочет обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен снова после уменьшения размера полей заголовка запроса.
Может использоваться, когда общий набор полей заголовка запроса слишком велик, а также когда это имеет место только с одним полем заголовка. В последнем случае ответ должен указать, какой из них слишком велик. Серверам не обязательно использовать код состояния 431 при атаке, поскольку иногда более предпочтительным вариантом является разрыв соединений.

444 Нет ответа (Nginx)

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

449 Повторить попытку с помощью (Microsoft)

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

450 Заблокировано родительским контролем Windows (Microsoft)

Это расширение Microsoft, которое появляется, когда родительский контроль Windows заблокировал доступ к определенной веб-странице.

451 Недоступно по юридическим причинам

Как следует из названия, используется, когда доступ к ресурсу запрещен по юридическим причинам. Бумага воспламеняется при температуре 451 ° F, поэтому было выбрано это число. Классический роман-антиутопия Рэя Брэдбери 1953 года «451 градус по Фаренгейту» исследует общество, в котором книги запрещены, а все найденные уничтожаются специальной командой «Пожарных».

499 Клиентский закрытый запрос (Nginx)

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

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

Когда коды состояния начинаются с «5», это означает, что сервер либо знает, что совершил ошибку, либо не может выполнить задачу. Если сервер не отвечает на запрос HEAD, он должен включать сущность, объясняющую, в чем заключается ошибка, и является ли она постоянной или временной. Пользовательские агенты должны показывать пользователю любой включенный объект. Эти коды будут применяться к любому методу запроса.

500 Internal Server Error

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

501 Не реализовано

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

502 Bad Gateway

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

503 Служба недоступна

В настоящее время сервер не может обработать запрос из-за технического обслуживания или временной перегрузки. Заголовок Retry-After можно использовать, чтобы показать, сколько времени займет решение проблемы. Если Retry-After не указан, клиент должен действовать так же, как если бы он получил ответ 500. Имейте в виду, что наличие кода состояния 503 не означает, что сервер должен использовать его, когда он испытывает перегрузку. Может просто отказать в соединении.

504 Тайм-аут шлюза

Пока сервер действовал как шлюз или прокси, он не получил своевременный ответ от вышестоящего сервера, указанного в URI (например, FTP, HTTP, LDAP) или от другого вспомогательного сервера (например, DNS), к которому ему нужно было получить доступ, пока он пытался выполнить запрос. Обратите внимание, что некоторые развернутые прокси, как известно, возвращают 400 или 500 ошибок, когда истекает время поиска DNS.

505 Версия HTTP не поддерживается

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

506 Вариант также согласовывает (экспериментальный)

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

507 Insufficient Storage (WebDAV)

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

508 Loop Detected (WebDAV)

Код состояния 508 (Loop Detected) отправляется вместо кода 208 и говорит о том, что сервер завершил операцию, потому что он столкнулся с бесконечным циклом во время обработки запроса. Это также указывает на то, что вся операция потерпела неудачу.

509 Превышен предел пропускной способности (Apache)

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

510 Не расширен

Дополнительные расширения запроса необходимы, чтобы сервер мог его выполнить. В запросе не соблюдена политика доступа к ресурсу. Сервер должен отправить обратно всю необходимую информацию, чтобы клиент мог выдать расширенный запрос. В рамки этой спецификации не входит определение того, как расширения должны передавать эту информацию клиенту.
. Если ответ 510 содержит информацию, относящуюся к расширениям, которых не было в исходном запросе, клиент МОЖЕТ сделать запрос снова, если он считает, что может выполнить политику расширений, изменив запрос в соответствии с информацией, указанной в 510. отклик. В качестве альтернативы клиент МОЖЕТ предложить пользователю любой объект, упомянутый в ответе 510, поскольку этот объект может иметь соответствующую диагностическую информацию для предоставления.

511 Требуется сетевая аутентификация

511 указывает, что клиент должен пройти аутентификацию, чтобы получить доступ к сети.
Представление ответа должно содержать ссылку на ресурс, который позволяет пользователю отправлять учетные данные (как, например, в форме HTML).
Имейте в виду, что ответ 511 не должен предлагать сам интерфейс входа или вызов, потому что (несколько сбивчиво) браузеры будут отображать интерфейс входа как связанный с URL-адресом, который был первоначально запрошен. Исходные серверы не должны выдавать статус 511. Он предназначен для перехвата промежуточных прокси-серверов с целью контроля доступа к сети.
511 Ответы с кодом состояния не должны кэшироваться.

Клиент должен пройти аутентификацию, чтобы получить доступ к сети. Этот код предназначен для устранения трудностей, связанных с «перехватывающими порталами» для программного обеспечения (особенно агентов, не являющихся браузерами), когда это программное обеспечение ожидает ответа от сервера, к которому был сделан запрос, а не от сетевой инфраструктуры между ними. Он не предназначен для того, чтобы препятствовать развертыванию порталов авторизации, а просто для того, чтобы свести к минимуму ущерб, который они могут нанести.

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

Впоследствии для неизвестных клиентов будет заблокирован весь трафик, кроме случаев, когда он поступает через TCP-порт 80, который направляется на HTTP-сервер («сервер входа в систему») и предназначен специально для «входа в систему» ​​неизвестных клиентов, и, естественно, трафик к сам логин-сервер.

Ответ, содержащий код состояния 511, обычно отправляется с исходного сервера, указанного в URL-адресе запроса, что создает множество проблем с безопасностью. Примеры включают в себя, когда атакующий посредник вставляет файлы cookie в пространство имен исходного домена, наблюдает за файлами cookie или учетными данными аутентификации HTTP, отправленными из пользовательского агента.
Однако эти риски не ограничиваются кодом состояния 511. Перехватывающий портал, который не использует этот код состояния, вызывает такие же трудности.
Также имейте в виду, что авторизованные порталы, использующие этот код состояния для соединения SSL или TLS (обычно порт 443), вызовут ошибку сертификата на клиенте.

598 Ошибка тайм-аута сетевого чтения

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

599 Ошибка тайм-аута сетевого подключения

Не указано ни в одном RFC, но некоторые прокси-серверы HTTP используют его для указания тайм-аута сетевого подключения за прокси-сервером к клиенту, который находится перед прокси-сервером.

Поиск

Больше результатов...

Общие фильтры

Скрытая этикетка

Только точные совпадения

Скрытый ярлык

Поиск по заголовку

Скрытый ярлык

Поиск по содержимому

Скрытая этикетка

Поиск по фрагменту

Мы Plesk

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

ПОЛУЧАЙТЕ ПОСЛЕДНИЕ НОВОСТИ И СОВЕТЫ

Похожие сообщения

База знаний

Все, что вам нужно знать о кодах состояния ответов HTTP | Томас Сентр

Коды ответов HTTP часто игнорируются, но они являются действительно важным механизмом для стандартизации ответов от удаленных серверов. Когда программа (или пользователь) отправляет запрос на сервер, может произойти следующее:

  • Проверка может не пройти
  • Проверка может быть успешной
  • Это может привести к ошибке сервера

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

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

В этом посте представлены несколько кодов состояния и ошибок сервера, а также объясняется, что они говорят о том, что происходит на сервере за кулисами.

Погружаемся!

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

Коды успеха используются для обозначения определенного уровня успеха HTTP-запроса. Это самые распространенные (и желаемые) коды.

Наиболее распространенные коды в этом диапазоне:

  • 200: Успех: Этот код указывает на полный успех. Ничего не пошло не так даже отдаленно.
  • 201: Created : Этот код используется в основном для REST API, когда клиент запрашивает создание нового объекта на сервере.
  • 203: Неавторизованная информация : Этот код предназначен для использования, когда при маршрутизации запроса через преобразующий прокси источник отвечает кодом 200.
  • 204: Нет контента : Это успешный код , но с сервера не возвращается контент. Иногда API возвращают 200, даже если контента нет.
  • 206: Частичное содержание : Этот код используется для разбитых на страницы ответов. Отправляется заголовок с указанием диапазона (и смещения), который будет принят клиентом. Если ответ превышает диапазон, сервер ответит 206, указывая на то, что есть еще данные.

Коды в диапазоне от 300 до 399 указывают на то, что клиент должен выполнить некоторые дополнительные действия для выполнения запроса.

Наиболее распространенные коды в этом диапазоне описываются следующим образом:

  • 301: перемещен навсегда : этот код состояния указывает, что ресурс, который пытался получить клиент, был навсегда перемещен в другое место.
  • 302: Найдено : Этот код указывает, что по какой-то причине пользователю необходимо выполнить временное перенаправление, но браузеры начали реализовывать этот код как 303 См. Другое. Это привело к введению временных кодов переадресации 303 и 307 для устранения неоднозначности поведения.
  • 308 Постоянное перенаправление: Этот код, как видно из названия, используется для указания постоянного перенаправления для ресурса. Его можно спутать с 301, но есть небольшая разница, код 308 не позволяет изменить метод HTTP.

Коды в диапазоне от 400 до 499 представляют ошибки, сгенерированные клиентом. Они указывают на то, что с запросом возникла проблема. Этот диапазон особенно важен, так как HTTP-серверы должны указывать клиентам, что с их запросом что-то не так.

Общие коды в этом диапазоне следующие:

  • 400 неверный запрос : этот код указывает, что запрос от пользователя синтаксически неверен. Могут отсутствовать параметры или некоторые значения не прошли проверку.
  • 401 Неавторизованный: Этот код указывает на отсутствие аутентификации клиента. Обычно действующий логин решает эту проблему.
  • 403 Запрещено: Это похоже на 401, но в данном случае указывает на то, что у пользователя недостаточно прав.
  • 404 Не найдено: Это означает, что ресурс не найден на сервере. Это ошибка, которую вы получаете, когда переходите на несуществующую страницу.

Этот диапазон указывает на то, что на сервере произошла ошибка обработки. Когда выдается код 5xx, это означает, что на сервере возникла какая-то проблема, и ее нельзя исправить с клиента.

Некоторые из кодов в этом диапазоне:

  • 500 Внутренняя ошибка сервера : Это означает, что в программном обеспечении на сервере произошла ошибка. Больше никакой информации не разглашается.
  • 501 Не реализовано: Этот код состояния ошибки указывает на то, что сервер не поддерживает функции, необходимые для выполнения запроса. Это подходящий ответ, когда сервер не распознает метод запроса и не может поддерживать его для любого ресурса.
  • 503 сервис недоступен: Этот код выдается, когда сервер недоступен по какой-то причине, либо превышение нагрузки, либо сервер не работает.

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

Не создавайте веб-монолиты. Используйте Bit для создания и компоновки несвязанных программных компонентов — в ваших любимых средах, таких как React или Node. Создавайте масштабируемые и модульные приложения с мощными и приятными возможностями разработки.

Пригласите свою команду в Bit Cloud , чтобы совместно размещать и совместно работать над компонентами, а также ускорять, масштабировать и стандартизировать разработку в команде. Попробуйте составных внешних интерфейсов с Design System или Micro Frontends или изучите составных внутренних компонентов с серверными компонентами .

Попробуйте →

Узнать больше

Как мы создаем микроинтерфейсы

Создание микроинтерфейсов для ускорения и масштабирования процесса веб-разработки.

blog.bitsrc.io

Как мы создаем систему проектирования компонентов

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

blog.bitsrc.io

Компонуемое предприятие: руководство

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

blog.bitsrc.io

7 инструментов для ускорения разработки внешнего интерфейса в 2022 году

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

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

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