Описания кодов состояния rfc 2068


Содержание

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

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

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

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

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

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

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

  • время изменения документа;
  • размер документа;
  • тип документа;
  • тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

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

Во втором случае передается только путь к документу.

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

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Передача данных в ответе сервера

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

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

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

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

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

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

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

А тело сообщения строится по следующим правилам

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

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

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

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

Каждое сообщение-ответ содержит код состояния, указывающий на результат выполнения запроса. разделены на те же пять категорий, что и коды ответов HTTP: информационные (lxx), успешного выполнения (2xx), нереадресации (Зхх), ошибки клиента (4xx) и ошибки сервера (5xx). В RTSP введено несколько новых кодов состояния, приведенных в таблице 12.8. RTSP также заимствовал многие коды состояния, определенные в документе RFC 2068 (см. таблицу 12.9). Во избежание конфликтов с новыми кодами ответов НТТР/1.1, которые могут появиться в будущем, специфические для RTSP коды начинаются с x50. Новые коды относятся к нескольким основным категориям:

• Системные ресурсы. Передача или прием мультимедийного потока может потребовать значительных ресурсов сервера. В ответ на запрос RECORD код состояния 250 Low on Storage Space предупреждает клиента, что на сервере отсутствует достаточный объем памяти для хранения записанного потока. Сервер может отклонить клиентский запрос на воспроизведение или запись потока, выдав ответ 453 Not Enough Bandwidth.

• Неизвестный идентификатор. Клиентский запрос может содержать переменную или адрес, которые сервер не распознает. При получении запроса SET_PARAMETER, который ссылается на неизвестный параметр, сервер посылает ответ 451 Parameter Not Understood. Аиалогично сервер посылает ответ 452 Conference Not Found или 454 Session Not Found при получении запроса с неизвестным идентификатором конференции Conference или сеанса Session, соответственно. Если сервер не может установить соединение для

доставки потока данных клиенту, сервер отправляет ответ 462 Destination Unreachable.

• Неподдерживаемая функция. Клиентский запрос может содержать метод или заголовок, который не поддерживается для ресурса с указанным в запросе URI. Например, некоторые методы могут быть некорректными для даипой ситуации (455 Method Not Valid in This State), а некоторые заголовки могут быть некорректными для определенных запрашиваемых URI (456 Header Field Not Valid for Resource). Запрос PLAY может пытаться осуществить перемещение в несуществующее место в потоке (457 Invalid Range), либо запрос SET_PARAMETER может пытаться осуществить запись параметра, предназначенного только для чтения (458 Parameter Is Read-Only). Заголовок Transport в запросе PLAY может не содержать поддерживаемой спецификации транспорта (461 Unsupported Transport), либо сервер может не поддерживать функцию, содержащуюся в заголовках Require или Proxy-Require (551 Option Not Supported).

• Операции с сеансом/потоком. Клиентский запрос может нарушать иерархию потока или сеанса. Например, клиентский запрос может пытаться выполнить операцию потокового уровня над идентифицируемым по URI запроса ресурсом, который является сеансом (459 Aggregate Operation Not Allowed), либо операцию сеансового уровня над ресурсом, который является потоком (460 Only Aggregate Operation Allowed).

Большинство новых кодов состояния относится к ошибкам клиента (4xx), за ис ключением кодов 250 Low on Storage space и 551 Option Not Supported, которые представляют собой код успешного выполпепия и код ошибки сервера, соответственно.

Таблица 12.8. Новые коды состояния RTSP

Код состояния и краткое описание

250 Low on Storage Space (Недостаточно памяти для хранения)

453 Not Enough Bandwidth (Пропускная способность недостаточна)

451 Parameter Not Understood (Параметр не может быть распознан)

452 Confcrence Not Found (Конференция не найдена)

454 Session Not Found (Сеанс не найден)

462 Destination Unreachable (Место назначения недостижимо)

455 Method Not Valid in This State (Неверный метод для данного состояния)

456 Header Field Not Valid for Resource (Неверное поле заголовка для ресурса)

457 Invalid Range (Неверный интервал)

458 Parameter Is Read-Only (Параметр только для чтения)

461 Unsupported Transport (Неподдерживаемый транспорт)

551 Option Not Supported (Опция не поддерживается)

Код состояния и краткое описание

459 Aggregate Operation Not Allowed (Операция агрегирования запрещена)

460 Only Aggregate Operation Allowed (Разрешена только операция агрегирования)

Резюмируя, можно сказать, что RTSP представляет собой протокол для доставки мультимедийных потоков, производный от НТТР/1.1 (см. таблицу 12.9). Протокол поддерживает воспроизведение мультимедийных данных с сервера и запись мультимедийных данных на сервер. RTSP и HTTP имеют сходную инфраструктуру для применения метода запроса к ресурсу, идентифицируемому URI, в соответствии с которой сообщение-запрос и сообщение-ответ содержат заголовки и необязательное содержимое. Спецификация RTSP во многом следует концепциям НТТР/1.1, связанным с кэшированием, серверами-посредниками и аутентификацией. Эти сходные черты проявляют себя во многих заголовках и кодах состояния RTSP, заимствованных из НТТР/1.1. Тем не менее, RTSP имеет ряд существенных отличий от HTTP. RTSP представляет собой протокол с сохранением промежуточного состояния, а передача данных осуществляется по другим протоколам. Кроме того, в RTSP определено несколько дополнительных заголовков и кодов состояния, которые связаны уникальными для мультимедийных потоков требованиями таймирования, а также к иерархическими отношениями между кадрами, потоками и сеансами. Эти характеристики проявляют себя в добавленных методах запросов, заголовках и кодах состояния.

Таблица 12.9. , заимствованные из НТТР/1.1

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Hypertext Transfer Protocol — HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as «HTTP/1.1», and is an update to RFC 2068 [33].

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

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

1xx: Information

В этот класс выделены коды, информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков для этого класса кодов состояния. Из-за того, что стандарт протокола HTTP/1.0 не определял никаких 1xx кодов состояния, серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам, за исключением экспериментальных условий.

Клиент должен быть готов принять один или несколько 1xx ответов статуса до завершения передачи, даже если клиент не ожидает статуса 100 (Продолжить). Неожиданные 1xx ответы могут быть проигнорированы агентом пользователя.

Прокси должен направить 1xx ответы, если соединение между прокси сервером и клиентом было закрыто, или если прокси сам просил 1xx ответ. (Например, если прокси добавляет «Expect: 100-continue» поле, когда он перенаправляет запрос, то нужно отправить соответствующий 100 (Continue) код ответа).


Wikipedia

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

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

Wikipedia

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

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

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

Wikipedia

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

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

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

Wikipedia

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

2xx: Success

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

Wikipedia

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

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

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

Wikipedia

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

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

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

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

Wikipedia

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

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

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

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

Wikipedia

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

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

Wikipedia

Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

Появился в HTTP/1.1.

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

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

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

Wikipedia

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

Статус используется, когда ответ не используется или когда нет контента (например при выполнении команды DELETE)

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяетс для возврата в начальное состояние формы ввода данных на клиенте.

Wikipedia

Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

Сервер выполнил часть 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) позволяет передавать статусы для нескольких независимых операций (за подробностями в секцию 11).

Wikipedia

Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

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

Wikipedia

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

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

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

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

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

Wikipedia

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

3xx: Redirect

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

Замечание: предыдущая версия спецификации допускала максимум 5 редиректов. Разработчики должны иметь это ввиду.

Wikipedia

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

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

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

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

Wikipedia

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

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

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

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

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

Wikipedia

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

Запрошенный ресурс временно находится под другим 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.

Документ по запрошенному аресу может быть найден по другому 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

Если клиент выполнил условный запрос 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 заголовки. Тело ответа при этом статусе не передается.

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

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

Wikipedia

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

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

Wikipedia

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

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

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

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

Wikipedia

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

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

Wikipedia

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

4xx: Client Error

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

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

Wikipedia

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

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

Wikipedia

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

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

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

Wikipedia

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

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

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

Wikipedia

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

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

Wikipedia

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

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

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

Wikipedia

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

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

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

Wikipedia

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

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

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

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

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

Wikipedia

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

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

Wikipedia

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

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

Wikipedia

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

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

Как правило, конфликты происходят во время 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.

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

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

Wikipedia

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

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

Wikipedia

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

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

Wikipedia

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

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

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

Wikipedia

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

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

Wikipedia

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


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

Wikipedia

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

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

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

Wikipedia

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

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

Wikipedia

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

Wikipedia

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

Wikipedia

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

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

Wikipedia

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

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

Wikipedia

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

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

Wikipedia

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

Slein, J., Whitehead, E.J., et al., «WebDAV Advanced Collections Protocol», Work In Progress.

Wikipedia

Defined in drafts of «WebDAV Advanced Collections Protocol», but not present in «Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol».

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

Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.

Wikipedia

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

The 428 status code indicates that the origin server requires the request to be conditional.

Its typical use is to avoid the «lost update» problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.

Responses using this status code SHOULD explain how to resubmit the request successfully.

The 428 status code is optional; clients cannot rely upon its use to prevent «lost update» conflicts.

Wikipedia

The origin server requires the request to be conditional. Intended to prevent «the «lost update» problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

The 429 status code indicates that the user has sent too many requests in a given amount of time («rate limiting»).

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.

Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes.

The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.

It can be used both when the set of request header fields in total are too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.

Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.

Wikipedia

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

Wikipedia

A Microsoft extension. The request should be retried after performing the appropriate action.

Wikipedia

A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.

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

Wikipedia

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

Wikipedia

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

5xx: Server Error

Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. Кроме HEAD-запросов, серверу следует включить в ответ сущность, содержащую объяснение ошибки, и является ли это временным или постоянным состоянием. Агентам СЛЕДУЕТ показывать включенную сущность пользователям. Этот код ответа подходит для любых методов запросов.

Wikipedia

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

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

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

Wikipedia

Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

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

Сервер не поддерживает функциональных возможностей, необходимых для выполнения запроса. Это типичный ответ, когда сервер не понимает метод в запросе и не способен выполнить запрос для ресурса. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

Wikipedia

Серверу либо не известен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос.

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился для выполнения запроса. Появился в HTTP/1.0.

Wikipedia

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера.

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время извстно, то его МОЖНО передать в заголовке Retry-After. Если заголовок Retry-After передан, то клиенту СЛЕДУЕТ обрабатывать ответ так, как если бы ответом был статус 500.

Замечание: существование кода 503 не обязывает сервер отвечать этим статусом, когда он перегружен. Некоторые сервера просто отвергают соединения.

Wikipedia

Сервер недоступен (из-за перегрузки или технических работ). Обычно это временное состояние.

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

Замечание: Некоторые прокси-сервера возвращают 400 или 500, когда время обраборки DNS запроса превышает установленный таймаут.

Wikipedia

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

Илон Маск рекомендует:  Алгоpитм плавающий гоpизонт

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

Wikipedia

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

The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

Wikipedia

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

The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.

Wikipedia

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

The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with «Depth: infinity». This status indicates that the entire operation failed.

Wikipedia

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


Wikipedia

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

The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.

If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.

Wikipedia

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

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

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

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

The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.

Responses with the 511 status code MUST NOT be stored by a cache.

The 511 status code is designed to mitigate problems caused by «captive portals» to software (especially non-browser agents) that is expecting a response from the server that a request was made to, not the intervening network infrastructure. It is not intended to encouraged deployment of captive portals, only to limit the damage caused by them.

A network operator wishing to require some authentication, acceptance of terms or other user interaction before granting access usually does so by identifing clients who have not done so («unknown clients») using their MAC addresses.

Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to a HTTP server (the «login server») dedicated to «logging in» unknown clients, and of course traffic to the login server itself.

In common use, a response carrying the 511 status code will not come from the origin server indicated in the request’s URL. This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain’s name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on.

However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.

Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client.

Wikipedia

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

Wikipedia

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

Wikipedia

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

«Top 10» HTTP код ответа. More REST service-specific information is contained in the entry.

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

Source ©Pearson eCollege, 2012. All rights reserved.

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

Что нужно знать про HTTP протокол веб-разработчику. Правила HTTP протокола

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике Cерверы и протоколы и ее разделе HTTP протокол. Данная запись является завершающей в цикле заметок по протоколу HTTP, после нее я подготовлю навигацию и, возможно, будут некоторые записи, связанные с протоколом HTTP, но не имеющие непосредственного к нему отношения. В принципе, эта запись поможет тебе понять, как работает HTTP протокол, а если нужны будут подробности — переходи по ссылкам, которые я для тебя расставил по всей статье.

Всё, что тебе нужно знать про HTTP протокол

Что такое HTTP протокол?

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

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

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

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

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

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

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

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

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

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные типы данных.

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола:

  1. HTTP протокол работает по технологии клиент-сервер.
  2. HTTP протокол относится к седьмому уровню модели OSI.
  3. HTTP протокол относится к семейству протоколов TCP/IP.
  4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
  5. Спецификация протокола RFC 2616.
  6. Для идентификации ресурса HTTP протокол использует URI (читай про URI в HTTP).
  7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
  8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

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

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. Клиент (в данном случае покупатель) полностью управляет развитием событий, то есть сервер (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

  1. Стандарт HTTP/0.9 – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
  2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
  3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, HTTP приложения могут себя идентифицировать, посылая информацию о себе в заголовке.
  4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

  • Google Chrome;
  • Mozilla FireFox;
  • Opera;
  • Internet Explorer;
  • Яндекс Браузер;
  • Safari.

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

Серверы HTTP протокола

Серверы HTTP протокола можно условно разделить на два вида: исходные сервера и прокси-сервера. К исходным серверам относятся те сервера, к которым непосредственно обращается клиент, прокси-сервера HTTP – это транзитные сервера между клиентом и тем сервером, к которому он желает обратиться. Зачастую бывает так, что HTTP сервер выполняет одновременно функцию и конечного сервера, и прокси-сервера, а иногда и клиента.

Вот примеры конечных HTTP серверов:

Давайте посмотрим на прокси-сервера:

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

Требования HTTP протокола

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

Структура HTTP протокола

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

  1. Стартовая строка или строка состояния, которая определяет тип HTTP сообщения. Стартовая строка обязательна для любого сообщения.
  2. Заголовок HTTP сообщения, который может включать одно поле Host или несколько полей для передачи различной служебной информации.
  3. Тело HTTP сообщения, которое содержит HTTP объекты. Тело сообщения служит для передачи пользовательской информации и есть не у каждого HTTP сообщения.

Терминология HTTP протокола

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

Параметры HTTP протокола

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

  1. Версия HTTP протокола является его обязательным параметром и указывается в первой строке любого HTTP сообщения.
  2. URI – это параметр, который позволяет однозначно идентифицировать ресурс, который хочет запросить клиент.
  3. Дата и время – это тоже параметр HTTP протокола.
  4. HTTP протокол имеет параметры кодирования сообщений и кодирования передачи.
  5. Тип данных или медиа тип – очередной параметр HTTP протокола.
  6. Лексемы программ позволяют определить разработчика HTTP приложения и версию приложения, а еще лексема является параметром HTTP протокола.
  7. HTTP протокол имеет параметры, которые позволяют определить язык сообщения, в HTTP это называется метка языка.
  8. А еще в HTTP есть единицы измерения диапазонов, которые позволяют запросить только часть ресурса.

Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ

Основной и единственной единицей измерения в HTTP протоколе является байт. Основным и единственным способом общения в HTTP протоколе является HTTP сообщение. Сообщения делятся на два вида: HTTP запрос – это сообщение, которое клиент посылает серверу и HTTP ответ – это сообщение, которое сервер посылает клиенту. В принципе, мы уже разобрались со структурой HTTP сообщения ранее, давайте теперь посмотрим примеры запросов и ответов в HTTP протоколе.

Давайте сначала посмотрим на то, что есть общего у любого сообщения в HTTP протоколе. Первое, что хочется выделить – это структура, она общая: статусная строка обязательна для всех сообщений, далее идет заголовок сообщения, в котором обязательное поле Host (в него записывается URI ресурса) и необязательное тело сообщения или, как его еще называют HTTP объект.

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

  1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
  2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
  3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
  4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
  5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

Простой пример запроса в HTTP протоколе: сначала идет статусная строка, в которой мы указываем версию протокола HTTP и метод, который будет использован для обращения к ресурсу, а скрипт, находящийся по URL /cgi-bin/process.cgi будет использован для обработки данных. Статусная строка отделена символом CRLF в конце от заголовка, далее идет набор полей HTTP заголовка, которые отделяются друг от друга символом CRLF в конце строки. Если у одного поля есть несколько значений, то они отделяются друг от друга запятой. Тело сообщения отделено пустой строкой. Значение и описание всех полей заголовка HTTP протокола вы сможете найти на моем блоге в специальной записи: список полей HTTP заголовка.

А вот пример ответа в протоколе HTTP:

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

Методы в HTTP протоколе

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

Методы в HTTP протоколе делятся на безопасные и идемпотентные. К безопасным относятся методы GET и HEAD, потому что они используются лишь для получения содержимого или его характеристик от сервера, а идемпотентные методы, это такие методы HTTP протокола, которые в случае своего многократного использования к ресурсу на одном и том же URI от одного и того же клиента будут давать такую же нагрузку, как будто этот метод выполнился только один раз, к идемпотентным методам HTTP протокола относятся: GET, HEAD, PUT, DELETE, OPTIONS и TRACE.

Давайте коротко рассмотрим методы HTTP протокола и их назначение:

  1. Метода GET в HTTP протоколе используется для получения информации от сервера по заданному URI. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
  2. Метод HTTP протокола HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
  3. Метод HTTP протокола POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
  4. Метода HTTP протокола PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.
  5. Метод HTTP протокола DELETE удаляет указанный в URI ресурс.
  6. Метод HTTP протокола CONNECT преобразует существующее соединение в тоннель.
  7. Метод HTTP протокола OPTIONS используется для получения параметров текущего HTTP соединения/.
  8. Метод HTTP протокола TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.


Как происходит соединение по HTTP протоколу

На данный момент для каждого HTTP соединения HTTP протокол поддерживает постоянные TCP соединения, это означает, что при повторном запросе к серверу с одним и тем же IP-адресом, соединение четвертого уровня рваться не будет, а будет использовано существующее. Раньше это было не так и, если в HTML документе были картинки, то для загрузки каждой картинки использовалось новое соединение TCP/IP.

Обсуждение содержимого в HTTP протоколе

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

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

Коды состояния в HTTP протоколе

Коды состояния в HTTP протоколе говорят клиенту о том, что произошло с его запросом, как сервер понял запрос и нужно ли делать что-нибудь клиенту, чтобы запрос был выполнен корректно. Коды состояния – это три цифры, например, 100, 301, 404, 503. Коды состояния в HTTP протоколе делятся на пять классов состояния: информационные коды (они начинаются с единицы), успешные коды (начинаются с двойки), коды перенаправления (начинаются с тройки), коды ошибок клиента (начинаются с четверки), коды ошибок сервера (начинаются с пятерки). Ниже приведена таблица классов кодов состояния их короткое описание. А еще вы можете посмотреть справочник кодов состояния.

Номер Класс кода состояния в HTTP протоколе и его описание
1 HTTP коды состояний 1xx: информационные

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

2 HTTP коды состояний 2xx: успешные

Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента.

3 HTTP коды состояний 3xx: перенаправление

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

4 HTTP коды состояний 4xx: ошибка клиента

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

5 HTTP коды состояний 5xx: серверная ошибка

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

Поля заголовка HTTP сообщения

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

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

  1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
  2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
  3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
  4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Более подробно о полях заголовков HTTP сообщения смотрите справочник полей заголовка HTTP сообщения.

Кэширование HTTP протокола

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

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

Номер Директивы поля заголовка Cache Control для клиента и их описание
1 no cache

Директива HTTP протокола no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.

2 no store

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

3 max age = seconds

Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.

4 max stale [ = seconds ]

Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.

5 min fresh = seconds

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

6 Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7 only if cached
Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.
Номер Директивы поля заголовка Cache Control для сервера и их описание
1 public

Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше.

2 private

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

3 no cache

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

4 no store

Директива HTTP протокола no store говорит о том, что ответ сервера нельзя сохранять в кэше.

5 no transform

Директива HTTP протокола no transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.

6 must revalidate

Директива HTTP протокола must revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.

7 proxy revalidate

Директива HTTP протокола proxy revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.

8 max age = seconds

Директива HTTP протокола max age говорит о том, сколько живет кэш на сервере.

9 Директива поля заголовка Cache Control ответа сервера: s maxage = seconds

Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов

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

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

А еще HTTP протокол позволяет присваивать каждому HTTP объекту тэг в поле заголовка ETag, по сути, это хэш сумма самого объекта и для каждого неповторяющегося объекта она уникальная, поэтому механизм кэширования HTTP протокола активно использует данное поле для проверки актуальности данных, которые хранятся в кэше.

Безопасность HTTP протокола

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

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

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

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

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

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

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

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

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

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

  • 1xx: Informational (информационные):
    • 100 Continue («продолжай») [2][3] ;
    • 101 Switching Protocols («переключение протоколов») [2][3] ;
    • 102 Processing («идёт обработка»).
  • 2xx: Success (успешно):
    • 200 OK («хорошо») [2][3] ;
    • 201 Created («создано») [2][3][4] ;
    • 202 Accepted («принято») [2][3] ;
    • 203 Non-Authoritative Information («информация не авторитетна») [2][3] ;
    • 204 No Content («нет содержимого») [2][3] ;
    • 205 Reset Content («сбросить содержимое») [2][3] ;
    • 206 Partial Content («частичное содержимое») [2][3] ;
    • 207 Multi-Status («многостатусный») [5] ;
    • 208 Already Reported («уже сообщалось») [6] ;
    • 226 IM Used («использовано IM»).
  • 3xx: Redirection (перенаправление):
    • 300 Multiple Choices («множество выборов») [2][7] ;
    • 301 Moved Permanently («перемещено навсегда») [2][7] ;
    • 302 Moved Temporarily («перемещено временно») [2][7] ;
    • 302 Found («найдено») [7] ;
    • 303 See Other («смотреть другое») [2][7] ;
    • 304 Not Modified («не изменялось») [2][7] ;
    • 305 Use Proxy («использовать прокси») [2][7] ;
    • 306 — зарезервировано (код использовался только в ранних спецификациях) [7] ;
    • 307 Temporary Redirect («временное перенаправление») [7] ;
    • 308 Permanent Redirect («постоянное перенаправление») [8] .
  • 4xx: Client Error (ошибка клиента):
    • 400 Bad Request («плохой, неверный запрос») [2][3][4] ;
    • 401 Unauthorized («не авторизован (не представился)») [2][3] ;
    • 402 Payment Required («необходима оплата») [2][3] ;
    • 403 Forb >[2][3] ;
    • 404 Not Found («не найдено») [2][3] ;
    • 405 Method Not Allowed («метод не поддерживается») [2][3] ;
    • 406 Not Acceptable («неприемлемо») [2][3] ;
    • 407 Proxy Authentication Required («необходима аутентификация прокси») [2][3] ;
    • 408 Request Timeout («истекло время ожидания») [2][3] ;
    • 409 Conflict («конфликт») [2][3][4] ;
    • 410 Gone («удалён») [2][3] ;
    • 411 Length Required («необходима длина») [2][3] ;
    • 412 Precondition Failed («условие ложно») [2][3][9] ;
    • 413 Payload Too Large («полезная нагрузка слишком велика») [2][3] ;
    • 414 URI Too Long («URI слишком длинный») [2][3] ;
    • 415 Unsupported Media Type («неподдерживаемый тип данных») [2][3] ;
    • 416 Range Not Satisfiable («диапазон не достижим») [3] ;
    • 417 Expectation Failed («ожидание не удалось») [3] ;
    • 418 I’m a teapot («я — чайник»);
    • 419 Authentication Timeout (not in RFC 2616) («обычно ошибка проверки CSRF»);
    • 421 Misdirected Request[10] ;
    • 422 Unprocessable Entity («необрабатываемый экземпляр»);
    • 423 Locked («заблокировано»);
    • 424 Failed Dependency («невыполненная зависимость»);
    • 426 Upgrade Required («необходимо обновление»);
    • 428 Precondition Required («необходимо предусловие») [11] ;
    • 429 Too Many Requests («слишком много запросов») [11] ;
    • 431 Request Header Fields Too Large («поля заголовка запроса слишком большие») [11] ;
    • 449 Retry With («повторить с») [1] ;
    • 451 Unavailable For Legal Reasons («недоступно по юридическим причинам») [12] .
    • 499 Client Closed Request (клиент закрыл соединение);
  • 5xx: Server Error (ошибка сервера):
    • 500 Internal Server Error («внутренняя ошибка сервера») [2][3] ;
    • 501 Not Implemented («не реализовано») [2][3] ;
    • 502 Bad Gateway («плохой, ошибочный шлюз») [2][3] ;
    • 503 Service Unavailable («сервис недоступен») [2][3] ;
    • 504 Gateway Timeout («шлюз не отвечает») [2][3] ;
    • 505 HTTP Version Not Supported («версия HTTP не поддерживается») [2][3] ;
    • 506 Variant Also Negotiates («вариант тоже проводит согласование») [13] ;
    • 507 Insufficient Storage («переполнение хранилища»);
    • 508 Loop Detected («обнаружено бесконечное перенаправление») [14] ;
    • 509 Bandw >[11] ;
    • 520 Unknown Error («неизвестная ошибка») [15] ;
    • 521 Web Server Is Down («веб-сервер не работает») [15] ;
    • 522 Connection Timed Out («соединение не отвечает») [15] ;
    • 523 Origin Is Unreachable («источник недоступен») [15] ;
    • 524 A Timeout Occurred («время ожидания истекло») [15] ;
    • 525 SSL Handshake Failed («квитирование SSL не удалось») [15] ;
    • 526 Inval >[15] .

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

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

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

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

Успех

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

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

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

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) [17] . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

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

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

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

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

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


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

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

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

  • 500 Internal Server Error [22] — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в 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 Bandw > 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
  • 511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.
  • 520 Unknown Error, возникает когда сервер CDN не смог обработать ошибку веб-сервера; нестандартный код CloudFlare.
  • 521 Web Server Is Down, возникает когда подключения CDN отклоняются веб-сервером; нестандартный код CloudFlare.
  • 522 Connection Timed Out, возникает когда CDN не удалось подключиться к веб-серверу; нестандартный код CloudFlare.
  • 523 Origin Is Unreachable, возникает когда веб-сервер недостижим; нестандартный код CloudFlare.
  • 524 A Timeout Occurred, возникает при истечении тайм-аута подключения между сервером CDN и веб-сервером; нестандартный код CloudFlare.
  • 525 SSL Handshake Failed, возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером; нестандартный код CloudFlare.
  • 526 Inval > См. также

Примечания

  1. 122.2.6 449 «Retry With Status Code» // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. на сайте MSDN
  2. 12345678910111213141516171819202122232425262728293031323334353637 «6.1.1 Status Code and Reason Phrase» в RFC 2068
  3. 123456789101112131415161718192021222324252627282930313233RFC 2616
  4. 123IETF Draft WebDAV Advanced Collections Protocol — S.4.2.5
  5. ↑IETF Draft WebDAV Advanced Collections Protocol — S.10
  6. ↑rfc5842 .
  7. 12345678910RFC 2616 «10.3 Redirection 3xx» (стр. 61)
  8. ↑rfc7538 .
  9. ↑IETF Draft WebDAV Advanced Collections Protocol — S.4.3.1.1
  10. ↑rfc7540 .
  11. 1234RFC 6585
  12. 12IETF Draft A New HTTP Status Code to Report Legal Obstacles
  13. ↑RFC 2295 Transparent Content Negotiation in HTTP — S.8.1
  14. ↑IETF Draft WebDAV Advanced Collections Protocol — S.7.1
  15. 1234567Error Pages – CloudFlare Support
  16. ↑RFC 2068 «10.3 Redirection 3xx» (стр. 56).
  17. ↑RFC 2616, раздел «10.3.3 302 Found», страница 63.
  18. ↑Что означает 403 Forbidden?.
  19. ↑Причины появления ошибки 404 Not Found.
  20. ↑RFC 2324 — Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0).
  21. ↑draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Дата обращения 22 декабря 2015.
  22. ↑Описание ошибки 500 Internal Server Error.

Ссылки

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных изначально — в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных. Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

Потребителей (клиентов), которые инициируют соединение и посылают запрос;

Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году — в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (в частности, для этого используется HTTP-заголовок). Именно благодаря возможности указания способа кодирования сообщения, клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP — протокол прикладного уровня; аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Код состояния HTTP 301 или Moved Permanently (с англ. — «Перемещено навсегда») — стандартный код ответа HTTP, получаемый в ответ от сервера в ситуации, когда запрошенный ресурс был на постоянной основе перемещён в новое месторасположение, и указывающий на то, что текущие ссылки, использующие данный URL, должны быть обновлены. Адрес нового месторасположения ресурса указывается в поле Location получаемого в ответ заголовка пакета протокола HTTP. В RFC 2616 указано, что:

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

в случае, если метод запроса был не HEAD, то содержимое должно включать в себя небольшое гипертекстовое примечание с гиперссылкой на новый URL;

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

Код ответа, Код причины завершения или Код возврата (в англоязычной литературе также Cause code, Reason code, Status code, Disconnect code и т. д.) — в телекоммуникациях и программном обеспечении — цифровой код, сформированный узлом в результате выполнения запроса, который характеризует то или иное событие протокола или технологии, произошедшее на отвечающей стороне: успешное или неуспешное выполнение и т. д. Нередко коды ответа сопровождаются лаконичным комментарием на английском языке, а в ответном сообщении вместе с цифровым кодом и его расшифровкой может передаваться другая необходимая информация (например, запрошенные данные).

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

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

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

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

Код ошибки (англ. Error code) в программировании, — это номер (или сочетания буквы и номера), который соответствует конкретной проблеме в работе программы. Коды ошибок используются для идентификации неправильной работы аппаратного и программного обеспечения, неверного ввода данных пользователем без обработки возникающей при этом исключительной ситуации в коде программы, хотя иногда коды ошибок используются в сочетании с обработкой исключений. Коды ошибок не следует путать с кодами возврата, хотя они часто используются вместе при обработке ошибок. Одни из самых серьёзных кодов ошибок, которые могут встретить пользователи — это коды «Синего экрана смерти» операционной системы Microsoft Windows.

Ошибка 404 или Not Found («не найдено») — стандартный код ответа HTTP о том, что клиент был в состоянии общаться с сервером, но сервер не может найти данные согласно запросу. Ошибку 404 не следует путать с ошибкой «Сервер не найден» или иными ошибками, указывающими на ограничение доступа к серверу. Ошибка 404 означает, что запрашиваемый ресурс может быть доступен в будущем, что однако не гарантирует наличие прежнего содержания.

Пользователи наиболее часто сталкиваются с ошибкой 404 при посещении так называемых «битых» или «мёртвых ссылок», что делает, таким образом, ошибку 404 одной из наиболее узнаваемых ошибок в сети Интернет.

RFC 2068 расширенный BNF

Я пытаюсь разобрать заголовки запроса авторизации, см. Https://www.ietf.org/rfc/rfc2617.txt раздел 3.2.2. Там, дайджест-ответ определяется следующим образом:

Расширенный BNF, который используется здесь, определен в http://www.ietf.org/rfc/rfc2068.txt, раздел 2.1.

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

У меня есть некоторые вопросы относительно определения дайджест-ответа:

1) Является ли приведенный ниже дайджест-ответ действительным (если нет, почему)? username_1, username_2

2) Является ли следующий ответ дайджест действительным (если нет, почему)? имя пользователя, область, nonce, digest-uri

3) Является ли следующий дайджест-ответ действительным (если нет, почему)? username_1, realm, nonce, digest-uri, response, username_2

4) Возьмем возможные постановки для 1 # (a | b) и 1 # (a | [b]), и в чем разница?

Список кодов состояния HTTP (Cgbcjr rjljd cjcnjzybz HTTP)

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

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

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

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


Содержание

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

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

  • 1xx: Informational (информационные):
    • 100 Continue («продолжай») [2][3] ;
    • 101 Switching Protocols («переключение протоколов») [2][3] ;
    • 102 Processing («идёт обработка»).
  • 2xx: Success (успешно):
    • 200 OK («хорошо») [2][3] ;
    • 201 Created («создано») [2][3][4] ;
    • 202 Accepted («принято») [2][3] ;
    • 203 Non-Authoritative Information («информация не авторитетна») [2][3] ;
    • 204 No Content («нет содержимого») [2][3] ;
    • 205 Reset Content («сбросить содержимое») [2][3] ;
    • 206 Partial Content («частичное содержимое») [2][3] ;
    • 207 Multi-Status («многостатусный») [5] ;
    • 208 Already Reported («уже сообщалось») [6] ;
    • 226 IM Used («использовано IM»).
  • 3xx: Redirection (перенаправление):
    • 300 Multiple Choices («множество выборов») [2][7] ;
    • 301 Moved Permanently («перемещено навсегда») [2][7] ;
    • 302 Moved Temporarily («перемещено временно») [2][7] ;
    • 302 Found («найдено») [7] ;
    • 303 See Other («смотреть другое») [2][7] ;
    • 304 Not Modified («не изменялось») [2][7] ;
    • 305 Use Proxy («использовать прокси») [2][7] ;
    • 306 — зарезервировано (код использовался только в ранних спецификациях) [7] ;
    • 307 Temporary Redirect («временное перенаправление») [7] ;
    • 308 Permanent Redirect («постоянное перенаправление») [8] .
  • 4xx: Client Error (ошибка клиента):
    • 400 Bad Request («плохой, неверный запрос») [2][3][4] ;
    • 401 Unauthorized («не авторизован (не представился)») [2][3] ;
    • 402 Payment Required («необходима оплата») [2][3] ;
    • 403 Forb >[2][3] ;
    • 404 Not Found («не найдено») [2][3] ;
    • 405 Method Not Allowed («метод не поддерживается») [2][3] ;
    • 406 Not Acceptable («неприемлемо») [2][3] ;
    • 407 Proxy Authentication Required («необходима аутентификация прокси») [2][3] ;
    • 408 Request Timeout («истекло время ожидания») [2][3] ;
    • 409 Conflict («конфликт») [2][3][4] ;
    • 410 Gone («удалён») [2][3] ;
    • 411 Length Required («необходима длина») [2][3] ;
    • 412 Precondition Failed («условие ложно») [2][3][9] ;
    • 413 Payload Too Large («полезная нагрузка слишком велика») [2][3] ;
    • 414 URI Too Long («URI слишком длинный») [2][3] ;
    • 415 Unsupported Media Type («неподдерживаемый тип данных») [2][3] ;
    • 416 Range Not Satisfiable («диапазон не достижим») [3] ;
    • 417 Expectation Failed («ожидание не удалось») [3] ;
    • 418 I’m a teapot («я — чайник»);
    • 419 Authentication Timeout (not in RFC 2616) («обычно ошибка проверки CSRF»);
    • 421 Misdirected Request[10] ;
    • 422 Unprocessable Entity («необрабатываемый экземпляр»);
    • 423 Locked («заблокировано»);
    • 424 Failed Dependency («невыполненная зависимость»);
    • 426 Upgrade Required («необходимо обновление»);
    • 428 Precondition Required («необходимо предусловие») [11] ;
    • 429 Too Many Requests («слишком много запросов») [11] ;
    • 431 Request Header Fields Too Large («поля заголовка запроса слишком большие») [11] ;
    • 449 Retry With («повторить с») [1] ;
    • 451 Unavailable For Legal Reasons («недоступно по юридическим причинам») [12] .
    • 499 Client Closed Request (клиент закрыл соединение);
  • 5xx: Server Error (ошибка сервера):
    • 500 Internal Server Error («внутренняя ошибка сервера») [2][3] ;
    • 501 Not Implemented («не реализовано») [2][3] ;
    • 502 Bad Gateway («плохой, ошибочный шлюз») [2][3] ;
    • 503 Service Unavailable («сервис недоступен») [2][3] ;
    • 504 Gateway Timeout («шлюз не отвечает») [2][3] ;
    • 505 HTTP Version Not Supported («версия HTTP не поддерживается») [2][3] ;
    • 506 Variant Also Negotiates («вариант тоже проводит согласование») [13] ;
    • 507 Insufficient Storage («переполнение хранилища»);
    • 508 Loop Detected («обнаружено бесконечное перенаправление») [14] ;
    • 509 Bandw >[11] ;
    • 520 Unknown Error («неизвестная ошибка») [15] ;
    • 521 Web Server Is Down («веб-сервер не работает») [15] ;
    • 522 Connection Timed Out («соединение не отвечает») [15] ;
    • 523 Origin Is Unreachable («источник недоступен») [15] ;
    • 524 A Timeout Occurred («время ожидания истекло») [15] ;
    • 525 SSL Handshake Failed («квитирование SSL не удалось») [15] ;
    • 526 Inval >[15] .

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

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

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

  • Шаблон:anchor100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • Шаблон:anchor101 Switching Protocols — сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade . Сервер отправляет заголовок ответа Upgrade , указывая протокол, на который он переключился. Появился в HTTP/1.1.
  • Шаблон:anchor102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

Успех

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

  • Шаблон:anchor200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
  • Шаблон:anchor201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер может указать адреса (их может быть несколько) созданного ресурса в теле ответа, при этом предпочтительный адрес указывается в заголовке Location . Серверу рекомендуется указывать в теле ответа характеристики созданного ресурса и его адреса, формат тела ответа определяется заголовком Content-Type . При обработке запроса, новый ресурс должен быть создан до отправки ответа клиенту, иначе следует использовать ответ с кодом 202 . Появился в HTTP/1.0.
  • Шаблон:anchor202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
  • Шаблон:anchor203 Non-Authoritative Information — аналогично ответу 200 , но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
  • Шаблон:anchor204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
  • Шаблон:anchor 205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
  • Шаблон:anchor 206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (Подробнее…)
  • Шаблон:anchor 207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus . Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
  • Шаблон:anchor 208 Already Reported — члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова.
  • Шаблон:anchor 226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

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

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) [17] . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

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

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

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

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

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

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

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

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

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

Состояние отпатрулирована

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

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

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

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

Содержание

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

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

  • 1xx: Informational (информационные):
    • 100 Continue («продолжай») [2][3] ;
    • 101 Switching Protocols («переключение протоколов») [2][3] ;
    • 102 Processing («идёт обработка»).
  • 2xx: Success (успешно):
    • 200 OK («хорошо») [2][3] ;
    • 201 Created («создано») [2][3][4] ;
    • 202 Accepted («принято») [2][3] ;
    • 203 Non-Authoritative Information («информация не авторитетна») [2][3] ;
    • 204 No Content («нет содержимого») [2][3] ;
    • 205 Reset Content («сбросить содержимое») [2][3] ;
    • 206 Partial Content («частичное содержимое») [2][3] ;
    • 207 Multi-Status («многостатусный») [5] ;
    • 208 Already Reported («уже сообщалось») [6] ;
    • 226 IM Used («использовано IM»).
  • 3xx: Redirection (перенаправление):
    • 300 Multiple Choices («множество выборов») [2][7] ;
    • 301 Moved Permanently («перемещено навсегда») [2][7] ;
    • 302 Moved Temporarily («перемещено временно») [2][7] ;
    • 302 Found («найдено») [7] ;
    • 303 See Other («смотреть другое») [2][7] ;
    • 304 Not Modified («не изменялось») [2][7] ;
    • 305 Use Proxy («использовать прокси») [2][7] ;
    • 306 — зарезервировано (код использовался только в ранних спецификациях) [7] ;
    • 307 Temporary Redirect («временное перенаправление») [7] ;
    • 308 Permanent Redirect («постоянное перенаправление») [8] .
  • 4xx: Client Error (ошибка клиента):
    • 400 Bad Request («плохой, неверный запрос») [2][3][4] ;
    • 401 Unauthorized («не авторизован (не представился)») [2][3] ;
    • 402 Payment Required («необходима оплата») [2][3] ;
    • 403 Forb >[2][3] ;
    • 404 Not Found («не найдено») [2][3] ;
    • 405 Method Not Allowed («метод не поддерживается») [2][3] ;
    • 406 Not Acceptable («неприемлемо») [2][3] ;
    • 407 Proxy Authentication Required («необходима аутентификация прокси») [2][3] ;
    • 408 Request Timeout («истекло время ожидания») [2][3] ;
    • 409 Conflict («конфликт») [2][3][4] ;
    • 410 Gone («удалён») [2][3] ;
    • 411 Length Required («необходима длина») [2][3] ;
    • 412 Precondition Failed («условие ложно») [2][3][9] ;
    • 413 Payload Too Large («полезная нагрузка слишком велика») [2][3] ;
    • 414 URI Too Long («URI слишком длинный») [2][3] ;
    • 415 Unsupported Media Type («неподдерживаемый тип данных») [2][3] ;
    • 416 Range Not Satisfiable («диапазон не достижим») [3] ;
    • 417 Expectation Failed («ожидание не удалось») [3] ;
    • 418 I’m a teapot («я — чайник»);
    • 419 Authentication Timeout (not in RFC 2616) («обычно ошибка проверки CSRF»);
    • 421 Misdirected Request[10] ;
    • 422 Unprocessable Entity («необрабатываемый экземпляр»);
    • 423 Locked («заблокировано»);
    • 424 Failed Dependency («невыполненная зависимость»);
    • 426 Upgrade Required («необходимо обновление»);
    • 428 Precondition Required («необходимо предусловие») [11] ;
    • 429 Too Many Requests («слишком много запросов») [11] ;
    • 431 Request Header Fields Too Large («поля заголовка запроса слишком большие») [11] ;
    • 449 Retry With («повторить с») [1] ;
    • 451 Unavailable For Legal Reasons («недоступно по юридическим причинам») [12] .
    • 499 Client Closed Request (клиент закрыл соединение);
  • 5xx: Server Error (ошибка сервера):
    • 500 Internal Server Error («внутренняя ошибка сервера») [2][3] ;
    • 501 Not Implemented («не реализовано») [2][3] ;
    • 502 Bad Gateway («плохой, ошибочный шлюз») [2][3] ;
    • 503 Service Unavailable («сервис недоступен») [2][3] ;
    • 504 Gateway Timeout («шлюз не отвечает») [2][3] ;
    • 505 HTTP Version Not Supported («версия HTTP не поддерживается») [2][3] ;
    • 506 Variant Also Negotiates («вариант тоже проводит согласование») [13] ;
    • 507 Insufficient Storage («переполнение хранилища»);
    • 508 Loop Detected («обнаружено бесконечное перенаправление») [14] ;
    • 509 Bandw >[11] ;
    • 520 Unknown Error («неизвестная ошибка») [15] ;
    • 521 Web Server Is Down («веб-сервер не работает») [15] ;
    • 522 Connection Timed Out («соединение не отвечает») [15] ;
    • 523 Origin Is Unreachable («источник недоступен») [15] ;
    • 524 A Timeout Occurred («время ожидания истекло») [15] ;
    • 525 SSL Handshake Failed («квитирование SSL не удалось») [15] ;
    • 526 Inval >[15] .

Описание кодов [ | ]

Информационные [ | ]

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

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

Успех [ | ]

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

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

Перенаправление [ | ]

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) [17] . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

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

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

Ошибка клиента [ | ]

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

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

Ошибка сервера [ | ]

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

  • 500 Internal Server Error [22] — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в 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 технологией .
  • 507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
  • 509 Bandw > 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
  • 511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.
  • 520 Unknown Error, возникает когда сервер CDN не смог обработать ошибку веб-сервера; нестандартный код CloudFlare,
  • 521 Web Server Is Down, возникает когда подключения CDN отклоняются веб-сервером; нестандартный код CloudFlare.
  • 522 Connection Timed Out, возникает когда CDN не удалось подключиться к веб-серверу; нестандартный код CloudFlare.
  • 523 Origin Is Unreachable, возникает когда веб-сервер недостижим; нестандартный код CloudFlare.
  • 524 A Timeout Occurred, возникает при истечении таймаута подключения между сервером CDN и веб-сервером; нестандартный код CloudFlare.
  • 525 SSL Handshake Failed, возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером; нестандартный код CloudFlare.
  • 526 Inval > См. также [ | ]

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

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

  • 201 Webpage Created.
  • 401 Access allowed only for registered users.
  • 507 Insufficient Storage.

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

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

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

Содержание

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

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

  • 1xx: Informational (информационные):
    • 100 Continue («продолжай») [2][3] .
    • 101 Switching Protocols («переключение протоколов») [2][3] .
    • 102 Processing («идёт обработка»).
  • 2xx: Success (успешно):
    • 200 OK («хорошо») [2][3] .
    • 201 Created («создано») [2][3][4] .
    • 202 Accepted («принято») [2][3] .
    • 203 Non-Authoritative Information («информация не авторитетна») [2][3] .
    • 204 No Content («нет содержимого») [2][3] .
    • 205 Reset Content («сбросить содержимое») [2][3] .
    • 206 Partial Content («частичное содержимое») [2][3] .
    • 207 Multi-Status («многостатусный») [5] .
    • 226 IM Used («использовано IM»).
  • 3xx: Redirection (перенаправление):
    • 300 Multiple Choices («множество выборов») [2][6] .
    • 301 Moved Permanently («перемещено навсегда») [2][6] .
    • 302 Moved Temporarily («перемещено временно») [2][6] .
    • 302 Found («найдено») [6] .
    • 303 See Other (смотреть другое) [2][6] .
    • 304 Not Modified (не изменялось) [2][6] .
    • 305 Use Proxy («использовать прокси») [2][6] .
    • 306 — зарезервировано (код использовался только в ранних спецификациях) [6] .
    • 307 Temporary Redirect («временное перенаправление») [6] .
  • 4xx: Client Error (ошибка клиента):
    • 400 Bad Request («плохой, неверный запрос») [2][3][4] .
    • 401 Unauthorized («не авторизован») [2][3] .
    • 402 Payment Required («необходима оплата») [2][3] .
    • 403 Forb >[2][3] .
    • 404 Not Found («не найдено») [2][3] .
    • 405 Method Not Allowed («метод не поддерживается») [2][3] .
    • 406 Not Acceptable («неприемлемо») [2][3] .
    • 407 Proxy Authentication Required («необходима аутентификация прокси») [2][3] .
    • 408 Request Timeout («истекло время ожидания») [2][3] .
    • 409 Conflict («конфликт») [2][3][4] .
    • 410 Gone («удалён») [2][3] .
    • 411 Length Required («необходима длина») [2][3] .
    • 412 Precondition Failed («условие ложно») [2][3][7] .
    • 413 Request Entity Too Large («размер запроса слишком велик») [2][3] .
    • 414 Request-URI Too Large («запрашиваемый URI слишком длинный») [2][3] .
    • 415 Unsupported Media Type («неподдерживаемый тип данных») [2][3] .
    • 416 Requested Range Not Satisfiable («запрашиваемый диапазон не достижим») [3] .
    • 417 Expectation Failed («ожидаемое неприемлемо») [3] .
    • 422 Unprocessable Entity («необрабатываемый экземпляр»).
    • 423 Locked («заблокировано»).
    • 424 Failed Dependency («невыполненная зависимость»).
    • 425 Unordered Collection («неупорядоченный набор») [8] .
    • 426 Upgrade Required («необходимо обновление»).
    • 428 Precondition Required («необходимо предусловие») [9] .
    • 429 Too Many Requests («слишком много запросов») [9] .
    • 431 Request Header Fields Too Large («поля заголовка запроса слишком большие») [9] .
    • 444 Закрывает соединение без передачи заголовка ответа. Нестандартный код. [10]
    • 449 Retry With («повторить с») [1] .
    • 451 Unavailable For Legal Reasons («недоступно по юридическим причинам») [11] .
  • 5xx: Server Error (ошибка сервера):
    • 500 Internal Server Error («внутренняя ошибка сервера») [2][3] .
    • 501 Not Implemented («не реализовано») [2][3] .
    • 502 Bad Gateway («плохой, ошибочный шлюз») [2][3] .
    • 503 Service Unavailable («сервис недоступен») [2][3] .
    • 504 Gateway Timeout («шлюз не отвечает») [2][3] .
    • 505 HTTP Version Not Supported («версия HTTP не поддерживается») [2][3] .
    • 506 Variant Also Negotiates («вариант тоже проводит согласование») [12]
    • 507 Insufficient Storage («переполнение хранилища»).
    • 508 Loop Detected («обнаружено бесконечное перенаправление») [13] .
    • 509 Bandw >[9] .
    • 520 Web server is returning an unknown error. Возникает когда сервер CDN не смог обработать ошибку веб-сервера. Нестандартный код CloudFlare. [14]
    • 521 Web server is down. Возникает когда подключения CDN отклоняются веб-сервером. Нестандартный код CloudFlare. [14]
    • 522 Connection timed out. Возникает когда CDN не удалось подключиться к веб-серверу. Нестандартный код CloudFlare. [14]
    • 523 Origin is unreachable. Возникает когда веб-сервер не достижим. Нестандартный код CloudFlare. [14]
    • 524 A timeout occurred. Возникает при истечении таймаута подключения между сервером CDN и веб-сервером. Нестандартный код CloudFlare. [14]
    • 525 SSL handshake failed. Возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером. Нестандартный код CloudFlare. [14]
    • 526 Inval >[14]

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

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

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

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

Успех

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

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

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

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) [16] . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

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

HTTP
Постоянное соединение · Сжатие · HTTPS
Методы
OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH
Заголовки
Cookie · ETag · Location · Referer
DNT · X-Forwarded-For
Коды состояния
301 Moved permanently
302 Found
303 See Other
403 Forbidden
404 Not Found
451 Unavailable for Legal Reasons
Статус ответа Кэширование Если метод не GET или HEAD
301 Moved Permanently Можно как обычно. Спросить у пользователя подтверждения и запросить другой ресурс исходным методом.
307 Temporary Redirect Можно только если указан заголовок Cache-Control или Expires .
302 Found (HTTP/1.1)
302 Moved Temporarily (HTTP/1.0)
303 See Other Нельзя. Перейти автоматически, но уже методом GET .
  • 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
  • 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location . Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
  • 303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307 -ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET . Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST , включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303 , указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
  • 304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET , использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
  • 305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
  • 306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
  • 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

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

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

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

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

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

  • 500 Internal Server Error [22] — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в 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 Bandw > 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
  • 511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

См. также

Напишите отзыв о статье «Список кодов состояния HTTP»

Примечания

  1. 12 [msdn.microsoft.com/en-us/library/dd891478(PROT.10).aspx 2.2.6 449 «Retry With Status Code» // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions.] на сайте MSDN
  2. 12345678910111213141516171819202122232425262728293031323334353637 «[tools.ietf.org/html/rfc2068#section-6.1.1 6.1.1 Status Code and Reason Phrase]» в RFC 2068
  3. 123456789101112131415161718192021222324252627282930313233 [tools.ietf.org/html/rfc2616#section-10.3 RFC 2616]
  4. 123 [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-4.2.5 IETF Draft WebDAV Advanced Collections Protocol — S.4.2.5]
  5. [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-9.13 IETF Draft WebDAV Advanced Collections Protocol — S.10]
  6. 12345678910 [tools.ietf.org/html/rfc2616#section-10.3 RFC 2616 «10.3 Redirection 3xx» (стр. 61)]
  7. [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-4.3.1 IETF Draft WebDAV Advanced Collections Protocol — S.4.3.1.1]
  8. [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-5.3.2 IETF Draft WebDAV Advanced Collections Protocol — S.5.3.2]
  9. 1234RFC 6585
  10. [nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return Модуль ngx_http_rewrite_module Директивы].
  11. 12 [tools.ietf.org/html/draft-tbray-http-legally-restricted-status-02 IETF Draft A New HTTP Status Code to Report Legal Obstacles]
  12. [tools.ietf.org/html/rfc2295#section-8.1 RFC 2295 Transparent Content Negotiation in HTTP — S.8.1]
  13. [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-7.1 IETF Draft WebDAV Advanced Collections Protocol — S.7.1]
  14. 1234567 [support.cloudflare.com/hc/en-us/sections/200820298-Error-Pages Error Pages – CloudFlare Support]
  15. [tools.ietf.org/html/rfc2068#section-10.3 RFC 2068 «10.3 Redirection 3xx» (стр. 56)].
  16. RFC 2616, раздел «10.3.3 302 Found», [tools.ietf.org/html/rfc2616#page-63 страница 63].
  17. [www.pageranker.ru/articles/troubleshooting/167—403-forbidden.html Что означает 403 Forbidden?].
  18. [www.pageranker.ru/articles/troubleshooting/168—404-not-found.html Причины появления ошибки 404 Not Found].
  19. RFC 2324 — Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
  20. [tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-5.3.2 WebDAV Advanced Collections Protocol S.5.3.2]
  21. [datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/?include_text=1 draft-ietf-httpbis-legally-restricted-status-04]. datatracker.ietf.org. Проверено 22 декабря 2015.
  22. [www.pageranker.ru/articles/troubleshooting/941-chto-oznachaet-oshibka-500-internal-server-error.html Описание ошибки 500 Internal Server Error].

Ссылки

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

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

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

  • RFC 4918 Proposed Standard «[tools.ietf.org/html/rfc4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]» (англ.) (русск. «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WEBDAV)»); IETF, июнь 2007; Dusseault Ed. L. (CommerceNet (англ.) русск. ) — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
  • RFC 3229 Proposed standard «[tools.ietf.org/html/rfc3229 Delta encoding in HTTP]» (англ.) (русск. «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken (англ.) русск. ), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
  • RFC 2817 Proposed Standard «[tools.ietf.org/html/rfc2817 Upgrading to TLS Within HTTP/1.1]» (англ.) (русск. «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; Khare Rohit (англ.) русск. (4K Associates/UC Irvine (англ.) русск. ), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
  • RFC 2774 Experimental «[tools.ietf.org/html/rfc2774 An HTTP Extension Framework]» (англ.) (русск. «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
  • Internet Draft «[tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 WebDAV Advanced Collections Protocol]» (русск. «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (UC Irvine (англ.) русск. ), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (FileNet (англ.) русск. ), Crawford J. (IBM), Chihaya T. (DataChannel) — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
  • RFC 2518 Proposed Standard «[tools.ietf.org/html/rfc2518 HTTP Extensions for Distributed Authoring — WEBDAV]» (англ.) (русск. «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (UC Irvine (англ.) русск. ), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
  • RFC 2295 Experimental «[tools.ietf.org/html/rfc2295 Transparent Content Negotiation in HTTP]» (англ.) (русск. «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).
  • [msdn.microsoft.com/en-us/library/cc250046%28PROT.13%29.aspx Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions] (англ.) . Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Проверено 30 июля 2009.[www.webcitation.org/65WVloxS1 Архивировано из первоисточника 17 февраля 2012].
  • RFC 2324 Informational «[tools.ietf.org/html/rfc2774 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)]» (англ.) (русск. «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
  • KB 318380 [support.microsoft.com/kb/318380/ Коды состояния служб IIS] (рус.) . Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Проверено 16 января 2010.[www.webcitation.org/65WVmPE8h Архивировано из первоисточника 17 февраля 2012].
  • Koford Adam. [www.flickr.com/photos/apelad/sets/72157594388426362/detail/ HTTP errors] (англ.) . Flickr (23 ноября 2006). — иллюстрации кодов ошибок с 400 по 417 для облегчения запоминания посредством мнемотехники. Проверено 16 января 2010.[www.webcitation.org/65WVnkGcv Архивировано из первоисточника 17 февраля 2012].
Виды сайтов
и сервисов Создание
и обслуживание Типы макетов,
страниц, сайтов Техническое Социум и культура Этот список входит в число избранных списков и порталов русскоязычного раздела Википедии.

Отрывок, характеризующий Список кодов состояния HTTP

Выйдя в приемную из кабинета Кутузова, князь Андрей с бумагами подошел к товарищу,дежурному адъютанту Козловскому, который с книгой сидел у окна.
– Ну, что, князь? – спросил Козловский.
– Приказано составить записку, почему нейдем вперед.
– А почему?
Князь Андрей пожал плечами.
– Нет известия от Мака? – спросил Козловский.
– Нет.
– Ежели бы правда, что он разбит, так пришло бы известие.
– Вероятно, – сказал князь Андрей и направился к выходной двери; но в то же время навстречу ему, хлопнув дверью, быстро вошел в приемную высокий, очевидно приезжий, австрийский генерал в сюртуке, с повязанною черным платком головой и с орденом Марии Терезии на шее. Князь Андрей остановился.
– Генерал аншеф Кутузов? – быстро проговорил приезжий генерал с резким немецким выговором, оглядываясь на обе стороны и без остановки проходя к двери кабинета.
– Генерал аншеф занят, – сказал Козловский, торопливо подходя к неизвестному генералу и загораживая ему дорогу от двери. – Как прикажете доложить?
Неизвестный генерал презрительно оглянулся сверху вниз на невысокого ростом Козловского, как будто удивляясь, что его могут не знать.
– Генерал аншеф занят, – спокойно повторил Козловский.
Лицо генерала нахмурилось, губы его дернулись и задрожали. Он вынул записную книжку, быстро начертил что то карандашом, вырвал листок, отдал, быстрыми шагами подошел к окну, бросил свое тело на стул и оглянул бывших в комнате, как будто спрашивая: зачем они на него смотрят? Потом генерал поднял голову, вытянул шею, как будто намереваясь что то сказать, но тотчас же, как будто небрежно начиная напевать про себя, произвел странный звук, который тотчас же пресекся. Дверь кабинета отворилась, и на пороге ее показался Кутузов. Генерал с повязанною головой, как будто убегая от опасности, нагнувшись, большими, быстрыми шагами худых ног подошел к Кутузову.
– Vous voyez le malheureux Mack, [Вы видите несчастного Мака.] – проговорил он сорвавшимся голосом.
Лицо Кутузова, стоявшего в дверях кабинета, несколько мгновений оставалось совершенно неподвижно. Потом, как волна, пробежала по его лицу морщина, лоб разгладился; он почтительно наклонил голову, закрыл глаза, молча пропустил мимо себя Мака и сам за собой затворил дверь.
Слух, уже распространенный прежде, о разбитии австрийцев и о сдаче всей армии под Ульмом, оказывался справедливым. Через полчаса уже по разным направлениям были разосланы адъютанты с приказаниями, доказывавшими, что скоро и русские войска, до сих пор бывшие в бездействии, должны будут встретиться с неприятелем.
Князь Андрей был один из тех редких офицеров в штабе, который полагал свой главный интерес в общем ходе военного дела. Увидав Мака и услыхав подробности его погибели, он понял, что половина кампании проиграна, понял всю трудность положения русских войск и живо вообразил себе то, что ожидает армию, и ту роль, которую он должен будет играть в ней.
Невольно он испытывал волнующее радостное чувство при мысли о посрамлении самонадеянной Австрии и о том, что через неделю, может быть, придется ему увидеть и принять участие в столкновении русских с французами, впервые после Суворова.
Но он боялся гения Бонапарта, который мог оказаться сильнее всей храбрости русских войск, и вместе с тем не мог допустить позора для своего героя.
Взволнованный и раздраженный этими мыслями, князь Андрей пошел в свою комнату, чтобы написать отцу, которому он писал каждый день. Он сошелся в коридоре с своим сожителем Несвицким и шутником Жерковым; они, как всегда, чему то смеялись.
– Что ты так мрачен? – спросил Несвицкий, заметив бледное с блестящими глазами лицо князя Андрея.
– Веселиться нечему, – отвечал Болконский.
В то время как князь Андрей сошелся с Несвицким и Жерковым, с другой стороны коридора навстречу им шли Штраух, австрийский генерал, состоявший при штабе Кутузова для наблюдения за продовольствием русской армии, и член гофкригсрата, приехавшие накануне. По широкому коридору было достаточно места, чтобы генералы могли свободно разойтись с тремя офицерами; но Жерков, отталкивая рукой Несвицкого, запыхавшимся голосом проговорил:
– Идут!… идут!… посторонитесь, дорогу! пожалуйста дорогу!
Генералы проходили с видом желания избавиться от утруждающих почестей. На лице шутника Жеркова выразилась вдруг глупая улыбка радости, которой он как будто не мог удержать.
– Ваше превосходительство, – сказал он по немецки, выдвигаясь вперед и обращаясь к австрийскому генералу. – Имею честь поздравить.
Он наклонил голову и неловко, как дети, которые учатся танцовать, стал расшаркиваться то одной, то другой ногой.
Генерал, член гофкригсрата, строго оглянулся на него; не заметив серьезность глупой улыбки, не мог отказать в минутном внимании. Он прищурился, показывая, что слушает.
– Имею честь поздравить, генерал Мак приехал,совсем здоров,только немного тут зашибся, – прибавил он,сияя улыбкой и указывая на свою голову.
Генерал нахмурился, отвернулся и пошел дальше.
– Gott, wie naiv! [Боже мой, как он прост!] – сказал он сердито, отойдя несколько шагов.
Несвицкий с хохотом обнял князя Андрея, но Болконский, еще более побледнев, с злобным выражением в лице, оттолкнул его и обратился к Жеркову. То нервное раздражение, в которое его привели вид Мака, известие об его поражении и мысли о том, что ожидает русскую армию, нашло себе исход в озлоблении на неуместную шутку Жеркова.
– Если вы, милостивый государь, – заговорил он пронзительно с легким дрожанием нижней челюсти, – хотите быть шутом , то я вам в этом не могу воспрепятствовать; но объявляю вам, что если вы осмелитесь другой раз скоморошничать в моем присутствии, то я вас научу, как вести себя.
Несвицкий и Жерков так были удивлены этой выходкой, что молча, раскрыв глаза, смотрели на Болконского.
– Что ж, я поздравил только, – сказал Жерков.
– Я не шучу с вами, извольте молчать! – крикнул Болконский и, взяв за руку Несвицкого, пошел прочь от Жеркова, не находившего, что ответить.
– Ну, что ты, братец, – успокоивая сказал Несвицкий.
– Как что? – заговорил князь Андрей, останавливаясь от волнения. – Да ты пойми, что мы, или офицеры, которые служим своему царю и отечеству и радуемся общему успеху и печалимся об общей неудаче, или мы лакеи, которым дела нет до господского дела. Quarante milles hommes massacres et l’ario mee de nos allies detruite, et vous trouvez la le mot pour rire, – сказал он, как будто этою французскою фразой закрепляя свое мнение. – C’est bien pour un garcon de rien, comme cet individu, dont vous avez fait un ami, mais pas pour vous, pas pour vous. [Сорок тысяч человек погибло и союзная нам армия уничтожена, а вы можете при этом шутить. Это простительно ничтожному мальчишке, как вот этот господин, которого вы сделали себе другом, но не вам, не вам.] Мальчишкам только можно так забавляться, – сказал князь Андрей по русски, выговаривая это слово с французским акцентом, заметив, что Жерков мог еще слышать его.
Он подождал, не ответит ли что корнет. Но корнет повернулся и вышел из коридора.

Гусарский Павлоградский полк стоял в двух милях от Браунау. Эскадрон, в котором юнкером служил Николай Ростов, расположен был в немецкой деревне Зальценек. Эскадронному командиру, ротмистру Денисову, известному всей кавалерийской дивизии под именем Васьки Денисова, была отведена лучшая квартира в деревне. Юнкер Ростов с тех самых пор, как он догнал полк в Польше, жил вместе с эскадронным командиром.
11 октября, в тот самый день, когда в главной квартире всё было поднято на ноги известием о поражении Мака, в штабе эскадрона походная жизнь спокойно шла по старому. Денисов, проигравший всю ночь в карты, еще не приходил домой, когда Ростов, рано утром, верхом, вернулся с фуражировки. Ростов в юнкерском мундире подъехал к крыльцу, толконув лошадь, гибким, молодым жестом скинул ногу, постоял на стремени, как будто не желая расстаться с лошадью, наконец, спрыгнул и крикнул вестового.
– А, Бондаренко, друг сердечный, – проговорил он бросившемуся стремглав к его лошади гусару. – Выводи, дружок, – сказал он с тою братскою, веселою нежностию, с которою обращаются со всеми хорошие молодые люди, когда они счастливы.
– Слушаю, ваше сиятельство, – отвечал хохол, встряхивая весело головой.
– Смотри же, выводи хорошенько!
Другой гусар бросился тоже к лошади, но Бондаренко уже перекинул поводья трензеля. Видно было, что юнкер давал хорошо на водку, и что услужить ему было выгодно. Ростов погладил лошадь по шее, потом по крупу и остановился на крыльце.
«Славно! Такая будет лошадь!» сказал он сам себе и, улыбаясь и придерживая саблю, взбежал на крыльцо, погромыхивая шпорами. Хозяин немец, в фуфайке и колпаке, с вилами, которыми он вычищал навоз, выглянул из коровника. Лицо немца вдруг просветлело, как только он увидал Ростова. Он весело улыбнулся и подмигнул: «Schon, gut Morgen! Schon, gut Morgen!» [Прекрасно, доброго утра!] повторял он, видимо, находя удовольствие в приветствии молодого человека.
– Schon fleissig! [Уже за работой!] – сказал Ростов всё с тою же радостною, братскою улыбкой, какая не сходила с его оживленного лица. – Hoch Oestreicher! Hoch Russen! Kaiser Alexander hoch! [Ура Австрийцы! Ура Русские! Император Александр ура!] – обратился он к немцу, повторяя слова, говоренные часто немцем хозяином.
Немец засмеялся, вышел совсем из двери коровника, сдернул
колпак и, взмахнув им над головой, закричал:
– Und die ganze Welt hoch! [И весь свет ура!]
Ростов сам так же, как немец, взмахнул фуражкой над головой и, смеясь, закричал: «Und Vivat die ganze Welt»! Хотя не было никакой причины к особенной радости ни для немца, вычищавшего свой коровник, ни для Ростова, ездившего со взводом за сеном, оба человека эти с счастливым восторгом и братскою любовью посмотрели друг на друга, потрясли головами в знак взаимной любви и улыбаясь разошлись – немец в коровник, а Ростов в избу, которую занимал с Денисовым.
– Что барин? – спросил он у Лаврушки, известного всему полку плута лакея Денисова.
– С вечера не бывали. Верно, проигрались, – отвечал Лаврушка. – Уж я знаю, коли выиграют, рано придут хвастаться, а коли до утра нет, значит, продулись, – сердитые придут. Кофею прикажете?
– Давай, давай.
Через 10 минут Лаврушка принес кофею. Идут! – сказал он, – теперь беда. – Ростов заглянул в окно и увидал возвращающегося домой Денисова. Денисов был маленький человек с красным лицом, блестящими черными глазами, черными взлохмоченными усами и волосами. На нем был расстегнутый ментик, спущенные в складках широкие чикчиры, и на затылке была надета смятая гусарская шапочка. Он мрачно, опустив голову, приближался к крыльцу.
– Лавг’ушка, – закричал он громко и сердито. – Ну, снимай, болван!
– Да я и так снимаю, – отвечал голос Лаврушки.
– А! ты уж встал, – сказал Денисов, входя в комнату.
– Давно, – сказал Ростов, – я уже за сеном сходил и фрейлен Матильда видел.
– Вот как! А я пг’одулся, бг’ат, вчег’а, как сукин сын! – закричал Денисов, не выговаривая р . – Такого несчастия! Такого несчастия! Как ты уехал, так и пошло. Эй, чаю!
Денисов, сморщившись, как бы улыбаясь и выказывая свои короткие крепкие зубы, начал обеими руками с короткими пальцами лохматить, как пес, взбитые черные, густые волосы.
– Чог’т меня дег’нул пойти к этой кг’ысе (прозвище офицера), – растирая себе обеими руками лоб и лицо, говорил он. – Можешь себе пг’едставить, ни одной каг’ты, ни одной, ни одной каг’ты не дал.
Денисов взял подаваемую ему закуренную трубку, сжал в кулак, и, рассыпая огонь, ударил ею по полу, продолжая кричать.
– Семпель даст, паг’оль бьет; семпель даст, паг’оль бьет.
Он рассыпал огонь, разбил трубку и бросил ее. Денисов помолчал и вдруг своими блестящими черными глазами весело взглянул на Ростова.
– Хоть бы женщины были. А то тут, кг’оме как пить, делать нечего. Хоть бы дг’аться ског’ей.
– Эй, кто там? – обратился он к двери, заслышав остановившиеся шаги толстых сапог с бряцанием шпор и почтительное покашливанье.
– Вахмистр! – сказал Лаврушка.
Денисов сморщился еще больше.
– Сквег’но, – проговорил он, бросая кошелек с несколькими золотыми. – Г`остов, сочти, голубчик, сколько там осталось, да сунь кошелек под подушку, – сказал он и вышел к вахмистру.
Ростов взял деньги и, машинально, откладывая и ровняя кучками старые и новые золотые, стал считать их.
– А! Телянин! Здог’ово! Вздули меня вчег’а! – послышался голос Денисова из другой комнаты.
– У кого? У Быкова, у крысы?… Я знал, – сказал другой тоненький голос, и вслед за тем в комнату вошел поручик Телянин, маленький офицер того же эскадрона.
Ростов кинул под подушку кошелек и пожал протянутую ему маленькую влажную руку. Телянин был перед походом за что то переведен из гвардии. Он держал себя очень хорошо в полку; но его не любили, и в особенности Ростов не мог ни преодолеть, ни скрывать своего беспричинного отвращения к этому офицеру.
– Ну, что, молодой кавалерист, как вам мой Грачик служит? – спросил он. (Грачик была верховая лошадь, подъездок, проданная Теляниным Ростову.)
Поручик никогда не смотрел в глаза человеку, с кем говорил; глаза его постоянно перебегали с одного предмета на другой.
– Я видел, вы нынче проехали…
– Да ничего, конь добрый, – отвечал Ростов, несмотря на то, что лошадь эта, купленная им за 700 рублей, не стоила и половины этой цены. – Припадать стала на левую переднюю… – прибавил он. – Треснуло копыто! Это ничего. Я вас научу, покажу, заклепку какую положить.
– Да, покажите пожалуйста, – сказал Ростов.
– Покажу, покажу, это не секрет. А за лошадь благодарить будете.
– Так я велю привести лошадь, – сказал Ростов, желая избавиться от Телянина, и вышел, чтобы велеть привести лошадь.
В сенях Денисов, с трубкой, скорчившись на пороге, сидел перед вахмистром, который что то докладывал. Увидав Ростова, Денисов сморщился и, указывая через плечо большим пальцем в комнату, в которой сидел Телянин, поморщился и с отвращением тряхнулся.
– Ох, не люблю молодца, – сказал он, не стесняясь присутствием вахмистра.
Ростов пожал плечами, как будто говоря: «И я тоже, да что же делать!» и, распорядившись, вернулся к Телянину.
Телянин сидел всё в той же ленивой позе, в которой его оставил Ростов, потирая маленькие белые руки.
«Бывают же такие противные лица», подумал Ростов, входя в комнату.
– Что же, велели привести лошадь? – сказал Телянин, вставая и небрежно оглядываясь.
– Велел.
– Да пойдемте сами. Я ведь зашел только спросить Денисова о вчерашнем приказе. Получили, Денисов?
– Нет еще. А вы куда?
– Вот хочу молодого человека научить, как ковать лошадь, – сказал Телянин.
Они вышли на крыльцо и в конюшню. Поручик показал, как делать заклепку, и ушел к себе.
Когда Ростов вернулся, на столе стояла бутылка с водкой и лежала колбаса. Денисов сидел перед столом и трещал пером по бумаге. Он мрачно посмотрел в лицо Ростову.
– Ей пишу, – сказал он.
Он облокотился на стол с пером в руке, и, очевидно обрадованный случаю быстрее сказать словом всё, что он хотел написать, высказывал свое письмо Ростову.
– Ты видишь ли, дг’уг, – сказал он. – Мы спим, пока не любим. Мы дети пг`axa… а полюбил – и ты Бог, ты чист, как в пег’вый день создания… Это еще кто? Гони его к чог’ту. Некогда! – крикнул он на Лаврушку, который, нисколько не робея, подошел к нему.
– Да кому ж быть? Сами велели. Вахмистр за деньгами пришел.
Денисов сморщился, хотел что то крикнуть и замолчал.
– Сквег’но дело, – проговорил он про себя. – Сколько там денег в кошельке осталось? – спросил он у Ростова.
– Семь новых и три старых.
– Ах,сквег’но! Ну, что стоишь, чучела, пошли вахмистг’а, – крикнул Денисов на Лаврушку.
– Пожалуйста, Денисов, возьми у меня денег, ведь у меня есть, – сказал Ростов краснея.
– Не люблю у своих занимать, не люблю, – проворчал Денисов.
– А ежели ты у меня не возьмешь деньги по товарищески, ты меня обидишь. Право, у меня есть, – повторял Ростов.
– Да нет же.
И Денисов подошел к кровати, чтобы достать из под подушки кошелек.
– Ты куда положил, Ростов?
– Под нижнюю подушку.
– Да нету.
Денисов скинул обе подушки на пол. Кошелька не было.
– Вот чудо то!
– Постой, ты не уронил ли? – сказал Ростов, по одной поднимая подушки и вытрясая их.
Он скинул и отряхнул одеяло. Кошелька не было.
– Уж не забыл ли я? Нет, я еще подумал, что ты точно клад под голову кладешь, – сказал Ростов. – Я тут положил кошелек. Где он? – обратился он к Лаврушке.
– Я не входил. Где положили, там и должен быть.
– Да нет…
– Вы всё так, бросите куда, да и забудете. В карманах то посмотрите.
– Нет, коли бы я не подумал про клад, – сказал Ростов, – а то я помню, что положил.
Лаврушка перерыл всю постель, заглянул под нее, под стол, перерыл всю комнату и остановился посреди комнаты. Денисов молча следил за движениями Лаврушки и, когда Лаврушка удивленно развел руками, говоря, что нигде нет, он оглянулся на Ростова.
– Г’остов, ты не школьнич…
Ростов почувствовал на себе взгляд Денисова, поднял глаза и в то же мгновение опустил их. Вся кровь его, бывшая запертою где то ниже горла, хлынула ему в лицо и глаза. Он не мог перевести дыхание.
– И в комнате то никого не было, окромя поручика да вас самих. Тут где нибудь, – сказал Лаврушка.
– Ну, ты, чог’това кукла, повог`ачивайся, ищи, – вдруг закричал Денисов, побагровев и с угрожающим жестом бросаясь на лакея. – Чтоб был кошелек, а то запог’ю. Всех запог’ю!
Ростов, обходя взглядом Денисова, стал застегивать куртку, подстегнул саблю и надел фуражку.
– Я тебе говог’ю, чтоб был кошелек, – кричал Денисов, тряся за плечи денщика и толкая его об стену.
– Денисов, оставь его; я знаю кто взял, – сказал Ростов, подходя к двери и не поднимая глаз.
Денисов остановился, подумал и, видимо поняв то, на что намекал Ростов, схватил его за руку.
– Вздог’! – закричал он так, что жилы, как веревки, надулись у него на шее и лбу. – Я тебе говог’ю, ты с ума сошел, я этого не позволю. Кошелек здесь; спущу шкуг`у с этого мег`завца, и будет здесь.
– Я знаю, кто взял, – повторил Ростов дрожащим голосом и пошел к двери.
– А я тебе говог’ю, не смей этого делать, – закричал Денисов, бросаясь к юнкеру, чтоб удержать его.
Но Ростов вырвал свою руку и с такою злобой, как будто Денисов был величайший враг его, прямо и твердо устремил на него глаза.
– Ты понимаешь ли, что говоришь? – сказал он дрожащим голосом, – кроме меня никого не было в комнате. Стало быть, ежели не то, так…
Он не мог договорить и выбежал из комнаты.
– Ах, чог’т с тобой и со всеми, – были последние слова, которые слышал Ростов.
Ростов пришел на квартиру Телянина.
– Барина дома нет, в штаб уехали, – сказал ему денщик Телянина. – Или что случилось? – прибавил денщик, удивляясь на расстроенное лицо юнкера.
– Нет, ничего.
– Немного не застали, – сказал денщик.
Штаб находился в трех верстах от Зальценека. Ростов, не заходя домой, взял лошадь и поехал в штаб. В деревне, занимаемой штабом, был трактир, посещаемый офицерами. Ростов приехал в трактир; у крыльца он увидал лошадь Телянина.
Во второй комнате трактира сидел поручик за блюдом сосисок и бутылкою вина.
– А, и вы заехали, юноша, – сказал он, улыбаясь и высоко поднимая брови.
– Да, – сказал Ростов, как будто выговорить это слово стоило большого труда, и сел за соседний стол.
Оба молчали; в комнате сидели два немца и один русский офицер. Все молчали, и слышались звуки ножей о тарелки и чавканье поручика. Когда Телянин кончил завтрак, он вынул из кармана двойной кошелек, изогнутыми кверху маленькими белыми пальцами раздвинул кольца, достал золотой и, приподняв брови, отдал деньги слуге.
– Пожалуйста, поскорее, – сказал он.
Золотой был новый. Ростов встал и подошел к Телянину.
– Позвольте посмотреть мне кошелек, – сказал он тихим, чуть слышным голосом.
С бегающими глазами, но всё поднятыми бровями Телянин подал кошелек.
– Да, хорошенький кошелек… Да… да… – сказал он и вдруг побледнел. – Посмотрите, юноша, – прибавил он.
Ростов взял в руки кошелек и посмотрел и на него, и на деньги, которые были в нем, и на Телянина. Поручик оглядывался кругом, по своей привычке и, казалось, вдруг стал очень весел.
– Коли будем в Вене, всё там оставлю, а теперь и девать некуда в этих дрянных городишках, – сказал он. – Ну, давайте, юноша, я пойду.
Ростов молчал.
– А вы что ж? тоже позавтракать? Порядочно кормят, – продолжал Телянин. – Давайте же.
Он протянул руку и взялся за кошелек. Ростов выпустил его. Телянин взял кошелек и стал опускать его в карман рейтуз, и брови его небрежно поднялись, а рот слегка раскрылся, как будто он говорил: «да, да, кладу в карман свой кошелек, и это очень просто, и никому до этого дела нет».
– Ну, что, юноша? – сказал он, вздохнув и из под приподнятых бровей взглянув в глаза Ростова. Какой то свет глаз с быстротою электрической искры перебежал из глаз Телянина в глаза Ростова и обратно, обратно и обратно, всё в одно мгновение.
– Подите сюда, – проговорил Ростов, хватая Телянина за руку. Он почти притащил его к окну. – Это деньги Денисова, вы их взяли… – прошептал он ему над ухом.
– Что?… Что?… Как вы смеете? Что?… – проговорил Телянин.
Но эти слова звучали жалобным, отчаянным криком и мольбой о прощении. Как только Ростов услыхал этот звук голоса, с души его свалился огромный камень сомнения. Он почувствовал радость и в то же мгновение ему стало жалко несчастного, стоявшего перед ним человека; но надо было до конца довести начатое дело.
– Здесь люди Бог знает что могут подумать, – бормотал Телянин, схватывая фуражку и направляясь в небольшую пустую комнату, – надо объясниться…
– Я это знаю, и я это докажу, – сказал Ростов.
– Я…
Испуганное, бледное лицо Телянина начало дрожать всеми мускулами; глаза всё так же бегали, но где то внизу, не поднимаясь до лица Ростова, и послышались всхлипыванья.
– Граф!… не губите молодого человека… вот эти несчастные деньги, возьмите их… – Он бросил их на стол. – У меня отец старик, мать!…
Ростов взял деньги, избегая взгляда Телянина, и, не говоря ни слова, пошел из комнаты. Но у двери он остановился и вернулся назад. – Боже мой, – сказал он со слезами на глазах, – как вы могли это сделать?
– Граф, – сказал Телянин, приближаясь к юнкеру.
– Не трогайте меня, – проговорил Ростов, отстраняясь. – Ежели вам нужда, возьмите эти деньги. – Он швырнул ему кошелек и выбежал из трактира.

Вечером того же дня на квартире Денисова шел оживленный разговор офицеров эскадрона.
– А я говорю вам, Ростов, что вам надо извиниться перед полковым командиром, – говорил, обращаясь к пунцово красному, взволнованному Ростову, высокий штаб ротмистр, с седеющими волосами, огромными усами и крупными чертами морщинистого лица.
Штаб ротмистр Кирстен был два раза разжалован в солдаты зa дела чести и два раза выслуживался.
– Я никому не позволю себе говорить, что я лгу! – вскрикнул Ростов. – Он сказал мне, что я лгу, а я сказал ему, что он лжет. Так с тем и останется. На дежурство может меня назначать хоть каждый день и под арест сажать, а извиняться меня никто не заставит, потому что ежели он, как полковой командир, считает недостойным себя дать мне удовлетворение, так…
– Да вы постойте, батюшка; вы послушайте меня, – перебил штаб ротмистр своим басистым голосом, спокойно разглаживая свои длинные усы. – Вы при других офицерах говорите полковому командиру, что офицер украл…
– Я не виноват, что разговор зашел при других офицерах. Может быть, не надо было говорить при них, да я не дипломат. Я затем в гусары и пошел, думал, что здесь не нужно тонкостей, а он мне говорит, что я лгу… так пусть даст мне удовлетворение…
– Это всё хорошо, никто не думает, что вы трус, да не в том дело. Спросите у Денисова, похоже это на что нибудь, чтобы юнкер требовал удовлетворения у полкового командира?
Денисов, закусив ус, с мрачным видом слушал разговор, видимо не желая вступаться в него. На вопрос штаб ротмистра он отрицательно покачал головой.
– Вы при офицерах говорите полковому командиру про эту пакость, – продолжал штаб ротмистр. – Богданыч (Богданычем называли полкового командира) вас осадил.
– Не осадил, а сказал, что я неправду говорю.
– Ну да, и вы наговорили ему глупостей, и надо извиниться.
– Ни за что! – крикнул Ростов.
– Не думал я этого от вас, – серьезно и строго сказал штаб ротмистр. – Вы не хотите извиниться, а вы, батюшка, не только перед ним, а перед всем полком, перед всеми нами, вы кругом виноваты. А вот как: кабы вы подумали да посоветовались, как обойтись с этим делом, а то вы прямо, да при офицерах, и бухнули. Что теперь делать полковому командиру? Надо отдать под суд офицера и замарать весь полк? Из за одного негодяя весь полк осрамить? Так, что ли, по вашему? А по нашему, не так. И Богданыч молодец, он вам сказал, что вы неправду говорите. Неприятно, да что делать, батюшка, сами наскочили. А теперь, как дело хотят замять, так вы из за фанаберии какой то не хотите извиниться, а хотите всё рассказать. Вам обидно, что вы подежурите, да что вам извиниться перед старым и честным офицером! Какой бы там ни был Богданыч, а всё честный и храбрый, старый полковник, так вам обидно; а замарать полк вам ничего? – Голос штаб ротмистра начинал дрожать. – Вы, батюшка, в полку без году неделя; нынче здесь, завтра перешли куда в адъютантики; вам наплевать, что говорить будут: «между павлоградскими офицерами воры!» А нам не всё равно. Так, что ли, Денисов? Не всё равно?
Денисов всё молчал и не шевелился, изредка взглядывая своими блестящими, черными глазами на Ростова.
– Вам своя фанаберия дорога, извиниться не хочется, – продолжал штаб ротмистр, – а нам, старикам, как мы выросли, да и умереть, Бог даст, приведется в полку, так нам честь полка дорога, и Богданыч это знает. Ох, как дорога, батюшка! А это нехорошо, нехорошо! Там обижайтесь или нет, а я всегда правду матку скажу. Нехорошо!
И штаб ротмистр встал и отвернулся от Ростова.
– Пг’авда, чог’т возьми! – закричал, вскакивая, Денисов. – Ну, Г’остов! Ну!
Ростов, краснея и бледнея, смотрел то на одного, то на другого офицера.
– Нет, господа, нет… вы не думайте… я очень понимаю, вы напрасно обо мне думаете так… я… для меня… я за честь полка.да что? это на деле я покажу, и для меня честь знамени…ну, всё равно, правда, я виноват. – Слезы стояли у него в глазах. – Я виноват, кругом виноват!… Ну, что вам еще?…
– Вот это так, граф, – поворачиваясь, крикнул штаб ротмистр, ударяя его большою рукою по плечу.
– Я тебе говог’ю, – закричал Денисов, – он малый славный.
– Так то лучше, граф, – повторил штаб ротмистр, как будто за его признание начиная величать его титулом. – Подите и извинитесь, ваше сиятельство, да с.
– Господа, всё сделаю, никто от меня слова не услышит, – умоляющим голосом проговорил Ростов, – но извиняться не могу, ей Богу, не могу, как хотите! Как я буду извиняться, точно маленький, прощенья просить?
Денисов засмеялся.
– Вам же хуже. Богданыч злопамятен, поплатитесь за упрямство, – сказал Кирстен.
– Ей Богу, не упрямство! Я не могу вам описать, какое чувство, не могу…
– Ну, ваша воля, – сказал штаб ротмистр. – Что ж, мерзавец то этот куда делся? – спросил он у Денисова.
– Сказался больным, завтг’а велено пг’иказом исключить, – проговорил Денисов.
– Это болезнь, иначе нельзя объяснить, – сказал штаб ротмистр.
– Уж там болезнь не болезнь, а не попадайся он мне на глаза – убью! – кровожадно прокричал Денисов.
В комнату вошел Жерков.
– Ты как? – обратились вдруг офицеры к вошедшему.
– Поход, господа. Мак в плен сдался и с армией, совсем.
– Врешь!
– Сам видел.
– Как? Мака живого видел? с руками, с ногами?
– Поход! Поход! Дать ему бутылку за такую новость. Ты как же сюда попал?
– Опять в полк выслали, за чорта, за Мака. Австрийской генерал пожаловался. Я его поздравил с приездом Мака…Ты что, Ростов, точно из бани?
– Тут, брат, у нас, такая каша второй день.
Вошел полковой адъютант и подтвердил известие, привезенное Жерковым. На завтра велено было выступать.
– Поход, господа!
– Ну, и слава Богу, засиделись.

Кутузов отступил к Вене, уничтожая за собой мосты на реках Инне (в Браунау) и Трауне (в Линце). 23 го октября .русские войска переходили реку Энс. Русские обозы, артиллерия и колонны войск в середине дня тянулись через город Энс, по сю и по ту сторону моста.
День был теплый, осенний и дождливый. Пространная перспектива, раскрывавшаяся с возвышения, где стояли русские батареи, защищавшие мост, то вдруг затягивалась кисейным занавесом косого дождя, то вдруг расширялась, и при свете солнца далеко и ясно становились видны предметы, точно покрытые лаком. Виднелся городок под ногами с своими белыми домами и красными крышами, собором и мостом, по обеим сторонам которого, толпясь, лилися массы русских войск. Виднелись на повороте Дуная суда, и остров, и замок с парком, окруженный водами впадения Энса в Дунай, виднелся левый скалистый и покрытый сосновым лесом берег Дуная с таинственною далью зеленых вершин и голубеющими ущельями. Виднелись башни монастыря, выдававшегося из за соснового, казавшегося нетронутым, дикого леса; далеко впереди на горе, по ту сторону Энса, виднелись разъезды неприятеля.
Между орудиями, на высоте, стояли спереди начальник ариергарда генерал с свитским офицером, рассматривая в трубу местность. Несколько позади сидел на хоботе орудия Несвицкий, посланный от главнокомандующего к ариергарду.
Казак, сопутствовавший Несвицкому, подал сумочку и фляжку, и Несвицкий угощал офицеров пирожками и настоящим доппелькюмелем. Офицеры радостно окружали его, кто на коленах, кто сидя по турецки на мокрой траве.
– Да, не дурак был этот австрийский князь, что тут замок выстроил. Славное место. Что же вы не едите, господа? – говорил Несвицкий.
– Покорно благодарю, князь, – отвечал один из офицеров, с удовольствием разговаривая с таким важным штабным чиновником. – Прекрасное место. Мы мимо самого парка проходили, двух оленей видели, и дом какой чудесный!
– Посмотрите, князь, – сказал другой, которому очень хотелось взять еще пирожок, но совестно было, и который поэтому притворялся, что он оглядывает местность, – посмотрите ка, уж забрались туда наши пехотные. Вон там, на лужку, за деревней, трое тащут что то. .Они проберут этот дворец, – сказал он с видимым одобрением.
– И то, и то, – сказал Несвицкий. – Нет, а чего бы я желал, – прибавил он, прожевывая пирожок в своем красивом влажном рте, – так это вон туда забраться.
Он указывал на монастырь с башнями, видневшийся на горе. Он улыбнулся, глаза его сузились и засветились.
– А ведь хорошо бы, господа!
Офицеры засмеялись.
– Хоть бы попугать этих монашенок. Итальянки, говорят, есть молоденькие. Право, пять лет жизни отдал бы!
– Им ведь и скучно, – смеясь, сказал офицер, который был посмелее.
Между тем свитский офицер, стоявший впереди, указывал что то генералу; генерал смотрел в зрительную трубку.
– Ну, так и есть, так и есть, – сердито сказал генерал, опуская трубку от глаз и пожимая плечами, – так и есть, станут бить по переправе. И что они там мешкают?
На той стороне простым глазом виден был неприятель и его батарея, из которой показался молочно белый дымок. Вслед за дымком раздался дальний выстрел, и видно было, как наши войска заспешили на переправе.
Несвицкий, отдуваясь, поднялся и, улыбаясь, подошел к генералу.
– Не угодно ли закусить вашему превосходительству? – сказал он.
– Нехорошо дело, – сказал генерал, не отвечая ему, – замешкались наши.
– Не съездить ли, ваше превосходительство? – сказал Несвицкий.
– Да, съездите, пожалуйста, – сказал генерал, повторяя то, что уже раз подробно было приказано, – и скажите гусарам, чтобы они последние перешли и зажгли мост, как я приказывал, да чтобы горючие материалы на мосту еще осмотреть.
– Очень хорошо, – отвечал Несвицкий.
Он кликнул казака с лошадью, велел убрать сумочку и фляжку и легко перекинул свое тяжелое тело на седло.
– Право, заеду к монашенкам, – сказал он офицерам, с улыбкою глядевшим на него, и поехал по вьющейся тропинке под гору.
– Нут ка, куда донесет, капитан, хватите ка! – сказал генерал, обращаясь к артиллеристу. – Позабавьтесь от скуки.
– Прислуга к орудиям! – скомандовал офицер.
И через минуту весело выбежали от костров артиллеристы и зарядили.
– Первое! – послышалась команда.
Бойко отскочил 1 й номер. Металлически, оглушая, зазвенело орудие, и через головы всех наших под горой, свистя, пролетела граната и, далеко не долетев до неприятеля, дымком показала место своего падения и лопнула.
Лица солдат и офицеров повеселели при этом звуке; все поднялись и занялись наблюдениями над видными, как на ладони, движениями внизу наших войск и впереди – движениями приближавшегося неприятеля. Солнце в ту же минуту совсем вышло из за туч, и этот красивый звук одинокого выстрела и блеск яркого солнца слились в одно бодрое и веселое впечатление.

Илон Маск рекомендует:  Атрибут archive в HTML
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL