Гипертекстный протокол HTTP

Successful 2xx (Успешная доставка)

Этот класс статусного кода индицирует, что запрос клиента благополучно получен, понят и принят к исполнению.

200 OK

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

GET — в качестве отклика посылается объект, соответствующий запрошенному ресурсу;

HEAD — в качестве отклика посылаются поля заголовка объекта (без какого-либо тела), соответствующего запрошенному ресурсу;

POST — объект, описывающий или содержащий результат операции;

TRACE — объект, содержащий сообщение­запроса, в виде, полученном оконечным сервером.

201 Created (Создано)

Запрос исполнен, и в результате создан новый ресурс. Вновь созданный ресурс может быть доступен через URI, присланный в объекте отклика, со значащей частью URL ресурса в поле заголовка Location. Исходный сервер должен создать ресурс до отправки статусного кода 201. Если операция не может быть выполнена немедленно, сервер вместо этого должен откликнуться статусным кодом 202 (Accepted).

202 Accepted (Принято)

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

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

203 NonAuthoritative Information (Не надежная информация)

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

204 No Content (Никакого содержимого)

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

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

205 Reset Content (Сброс содержимого)

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

206 Partial Content (Частичное содержимое)

Сервер исполнил частично запрос GET для заданного ресурса. В запрос должно входить поле заголовка Range, указывающее на желательный интервал (range). Отклик должен включать поле заголовка ContentRange, которое указывает диапазон данных, включенных в отклик, или множественные байтные интервалы (multipart/byteranges) Content-Type, содержащие поля ContentRange для каждой из частей. Если множественные байтные интервалы не используются, поле заголовка ContentLength в отклике должно соответствовать действительному числу октетов в теле сообщения. Кэш, который не поддерживает заголовки Range и ContentRange, не должен кэшировать отклики 206 (Partial).

Redirection 3xx (Переадресация)

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

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

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

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

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

301 Moved Permanently (Постоянно перемещен)

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

Если новый URI является адресом (location), его URL должен быть задан в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.

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

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

302 Moved Temporarily (Временно перемещен)

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

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

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

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

303 See Other (смотри другие)

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

Если новый URI является адресом (location), его URL должно быть задано в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать гипертекстовую ссылку на новый URI.

304 Not Modified (Не модифицировано)

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

• дата;
• ETag и/или ContentLocation, если заголовок был послан в рамках отклика 200 на тот же самый запрос;
• Expires, Cache-Control и/или Vary, если значение поля может отличаться от посланного в каком­-либо предыдущем отклике того же варианта.

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

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

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

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

305 Use Proxy (Используйте прокси)

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

Client Error 4xx (Ошибка клиента)

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

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

400 Bad Request (Плохой запрос)

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

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

Запрос требует авторизации пользователя. Отклик должен включать в себя поле заголовка WWW-Authenticate, которое содержит требование (challenge), применимое к запрошенному ресурсу. Клиент может повторить запрос с соответствующим содержимым поля заголовка Authorization. Если запрос уже включал допуск в поле Authorization, тогда отклик 401 указывает на то, что данный допуск не работает. Если отклик 401 содержит то же требование, что и предшествующий отклик, а агент пользователя уже пробовал пройти идентификацию, по крайней мере, хотя бы раз, тогда пользователю следует предоставить объект, содержащийся в отклике, так как он может содержать полезную диагностическую информацию.

402 Необходима оплата

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

403 Forbidden (Запрещено)

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

404 Not Found (Не найдено)

Сервер не нашел ничего, отвечающего Request-URI. Не приводится никаких данных о том, являются ли эта ситуация временной или постоянной.

Если сервер не хочет сделать эту информацию открытой для клиента, он вместо этого может применить статусный код 403. Статусный код 410 ( Gone — Утрачен) следует использовать, если сервер знает за счет некоторого внутреннего механизма конфигурации, что старый ресурс постоянно недоступен, и не имеет нового адреса его размещения.

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

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

406 Not Acceptable (Не приемлемо)

Ресурс, идентифицированный запросом, способен только генерировать объекты откликов, которые имеют характеристики, неприемлемые согласно заголовкам accept, что присланы в запросе.

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

HTTP/1.1 серверам разрешено присылать отклики, которые неприемлемы согласно заголовкам accept, присланным в запросе. В некоторых случаях может оказаться предпочтительнее послать отклик 406. Агенты пользователя могут просматривать заголовки приходящих откликов, чтобы определить, являются ли они приемлемыми. Если отклик не может быть воспринят, агенту пользователя следует временно прервать прием данных и запросить пользователя принять решение о дальнейших действиях.

407 Proxy Authentication Required (Необходима идентификация прокси)

Этот статусный код подобен 401 (Unauthorized), но указывает, что клиент должен сначала авторизоваться на проксисервере. Прокси должен прислать в ответ поле заголовка Proxy-Authenticate, которое содержит требования, реализуемые на прокси для запрошенного ресурса. Клиент может повторить запрос с подходящим полем заголовка Proxy-Authorization.

408 Request Timeout (Таймаут запроса)

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

409 Conflict (Конфликт)

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

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

410 Gone (Исчез)

Запрошенный ресурс не является более доступным на сервере, и не известен указатель переадресации. Это условие следует считать постоянным. Клиенты с возможностями редактирования связей должны ликвидировать ссылки на Request-URI после подтверждения пользователем. Если сервер не знает или не имеет возможности определить, является ли данное условие постоянным или временным, следует использовать отклик со статусным кодом 404 (Not Found – не найден). Этот отклик можно кэшировать, если не указано обратного.

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

411 Length Required (Необходима длина)

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

412 Precondition Failed (Предварительные условия не выполнены)

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

413 Request Entity Too Large (Объект запроса слишком велик)

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

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

414 Request-URI Too Long (URI запроса слишком велик)

Сервер отказывается обслужить запрос, потому что Request-URI длиннее, чем сервер способен интерпретировать. Это редкое обстоятельство может возникнуть только, когда клиент не корректно преобразует запрос POST в GET с длинной информацией запроса. При этом клиент ныряет в "черную дыру" переадресаций. Примером может служить преадресованный URL префикс, который указывает на свой суффикс, или случай атаки сервера клиентом, который пытается использовать дыры в системе безопасности, имеющиеся у клиентов с фиксированной емкостью буферов для работы с Request-URI.

415 Unsupported Media Type (Неподдерживаемый тип среды)

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

Server error 5xx (ошибка сервера)

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

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

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

501 Not Implemented (Не применимо)

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

502 Bad Gateway (Плохой шлюз)

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

503 Service Unavailable (Услуга не доступна)

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

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

504 Gateway Timeout (Таймаут шлюза)

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

505 HTTP Version Not Supported (Версия не поддерживается)

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

Идентификация доступа (RFC-2617)

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

Authscheme  = token
authparam  = token "=" quotedstring

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

Challenge  = authscheme 1*SP realm *( "," authparam )
Realm    = "realm" "=" realmvalue
realmvalue  = quotedstring

Атрибут области realm необходим для всех схем идентификации (authentication), которые посылают требования. Значение атрибута realm (чувствительно к применению строчных и прописных букв), в комбинации с каноническим корневым URL сервера доступа, определяет пространство защиты. Эти области позволяют разделить защищенные ресурсы на сервере на ряд защищенных зон, каждая со своей собственной схемой идентификации и/или идентификационной базой данных. Значением атрибута области является строка, обычно присваиваемая исходным сервером, которая может иметь специфическую семантику для каждой схемы идентификации.

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

credentials = basiccredentials
      | authscheme #authparam

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

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

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

Прокси­серверы должны быть полностью прозрачны в отношении авторизации агентов пользователя. То есть, они должны переадресовывать в неприкосновенном виде заголовки WWW-Authenticate и Authorization.

HTTP/1.1 позволяет клиенту передать идентификационную информацию в прокси и обратно с использованием заголовков Proxy-Authenticate и Proxy-Authorization.