Эдесь представлен перевод документа RFC 2068 на русский язык. При
переводе я пользовался личным опытом и здравым смыслом, поэтому в
некоторых местах читатель, знакомый с оригиналом, может заметить
несущественные отличия. Я изо всех сил пытался придать удобочитаемый
вид, но в некоторых местах вы встретите предложения, написанные
"криво" (это связано либо с "техничностью" текста, либо с моими
проблемами в русском языке). Убедительная просьба : если
встретите опечатки, ошибки, или у вас появятся предложения по
улучшению отдельных фраз или целых фрагментов - сообщите мне по
адресу [email protected] .
Я отдаю себе отчет в том, что некоторые термины, возможно,
переведены некорректно. При сомнениях я добавлял английские термины
в круглых скобках. Например: запрос (request).
В содержании указаны страницы английского оригинала.
Этим переводом я не преследовал коммерческих целей, поэтому я не
несу ответственности за несоответствие русского перевода
английскому оригиналу. Если Вы желаете получить адекватный перевод
этого документа (или какого-либо другого по компьютерной тематике),
то я могу его переработать в соответствии с Вашими требованиями за
определенную плату (это связано с моим тяжелым финансовым положением
как студента).
Алексей Симонов.
Статус данного документа.
Этот документ определяет протокол дорожки стандартов Интернета
(Internet standards track protocol) для семейства Интернета, и
предназначен для обсуждения и предложений по усовершенствованию.
Пожалуйста обратитесь к текущему изданию "Официальных стандартов
протоколов Интернет" (STD 1) для выяснения состояния стандартизации
и статуса этого протокола. Распространение данного документа
неограничено.
Реферат.
Протокол передачи Гипертекста (HTTP) - протокол прикладного уровня
для распределенных, совместных, многосредных информационных систем.
Это общий, платформно-независимый, объектно-ориентированный протокол,
который может использоваться во многих задачах, таких как сервера
имен и распределенные системы управления объектами, посредством
расширения методов запроса.
Возможность HTTP - это печать и обсуждение представления данных,
позволяющее строить системы независимо от передаваемых данных.
HTTP используется в World Wide Web (WWW) начиная с 1990 года. Эта
спецификация определяет протокол, упоминаемый как "HTTP/1.1".
Содержание.
1 Введение ................................................7
1.1 Цель .................................................7
1.2 Требования ...........................................7
1.3 Терминология .........................................8
1.4 Общее описание ......................................11
2 Письменные соглашения и обобщенная грамматика ..........13
2.1 Увеличенная нормальная запись Бекуса-Наура (BNF) ....13
2.2 Основные правила ....................................15
3 Параметры протокола ....................................17
3.1 Версия HTTP .........................................17
3.2 Универсальные Идентификаторы Ресурсов (URI) .........18
3.2.1 Общий синтаксис ..................................18
3.2.2 HTTPURL .........................................19
3.2.3 Сравнение URI ....................................20
3.3 Форматы даты/времени ................................21
3.3.1 Полная дата ......................................21
3.3.2 Разность секунд (delta seconds) ..................22
3.4 Кодовые таблицы (character sets) ....................22
3.5 Кодирование содержимого (content codings) ...........23
3.6 Кодирование передачи (transfer codings) .............24
3.7 Медиа типы (Media Types) ............................25
3.7.1 Канонизация и предопределенные значения типа
text .............................................26
3.7.2 Типы Multipart ...................................27
3.8 Лексемы программ (Product Tokens) ...................28
3.9 Качественные значения (Quality Values) ..............28
3.10 Метки языков (Language Tags) .......................28
3.11 Метки объектов (Entity Tags) .......................29
3.12 Еденицы измерения диапазонов (Range Units) .........30
4 HTTP сообщение (HTTP Message) ..........................30
4.1 Типы сообщений ......................................30
4.2 Заголовки сообщений .................................31
4.3 Тело cообщения ......................................32
4.4 Длина сообщения .....................................32
4.5 Общие поля заголовка ................................34
5 Запрос (Request) .......................................34
5.1 Строка запроса (Request-Line) .......................34
5.1.1 Метод (Method) ...................................35
5.1.2 Запрашиваемый URI (Request-URI) ..................35
5.2 Ресурс, идентифицируемый запросом ...................37
5.3 Поля заголовка запроса ..............................37
6 Ответ (Response) .......................................38
6.1 Строка состояния (Status-Line) ......................38
6.1.1 Код состояния и поясняющая фраза .................39
6.2 Поля заголовка ответа ...............................41
7 Объект (Entity) ........................................41
7.1 Поля заголовка объекта ..............................41
7.2 Тело объекта ........................................42
7.2.1 Тип (Type) .......................................42
7.2.2 Длина (Length) ...................................43
8 Соединения (Connections) ...............................43
8.1 Постоянные соединения (Persistent Connections) ......43
8.1.1 Цель .............................................43
8.1.2 Общее описание ...................................44
8.1.3 Прокси-сервера (Proxy Servers) ...................45
8.1.4 Практические cоглашения ..........................45
8.2 Требования к передаче сообщений .....................46
9 Определения методов (Method Definitions) ...............48
? 9.1 Безопасные и Idempotent Методы ......................48
9.1.1 Безопасные методы ................................48
? 9.1.2 Idempotent методы (Idempotent Methods) ...........49
9.2 OPTIONS .............................................49
9.3 GET .................................................50
9.4 HEAD ................................................50
9.5 POST ................................................51
9.6 PUT .................................................52
9.7 DELETE ..............................................53
9.8 TRACE ...............................................53
10 Описания кодов состояния ..............................53
10.1 1xx - Информационные коды ..........................54
10.1.1 100 Продолжать, Continue ........................54
10.1.2 101 Переключение протоколов, Switching
Protocols ...................................54
10.2 2xx - Успешные коды ................................54
10.2.1 200 ОК ..........................................54
10.2.2 201 Создан, Created .............................55
10.2.3 202 Принято, Accepted ...........................55
10.2.4 203 Не авторская информация, Non-Authoritative
Information .................................55
10.2.5 204 Нет содержимого, No Content .................55
10.2.6 205 Сбросить содержимое, Reset Content ..........56
10.2.7 206 Частичное содержимое, Partial Content .......56
10.3 3xx - Коды перенаправления .........................56
10.3.1 300 Множественный выбор, Multiple Choices .......57
10.3.2 301 Постоянно перенесен, Moved Permanently ......57
10.3.3 302 Временно перемещен, Moved Temporarily .......58
10.3.4 303 Смотреть другой, See Other ..................58
10.3.5 304 Не модифицирован, Not Modified ..............58
10.3.6 305 Используйте прокси-сервер, Use Proxy ........59
10.4 4xx - Коды ошибок клиента ..........................59
10.4.1 400 Испорченный Запрос, Bad Request .............60
10.4.2 401 Несанкционированно, Unauthorized ............60
10.4.3 402 Требуется оплата, Payment Required ..........60
10.4.4 403 Запрещено, Forbidden ........................60
10.4.5 404 Не найден, Not Found ........................60
10.4.6 405 Метод не дозволен, Method Not Allowed .......61
10.4.7 406 Не приемлем, Not Acceptable .................61
10.4.8 407 Требуется установление подлинности через
прокси-сервер, Proxy Authentication
Required ....................................61
10.4.9 408 Истекло время ожидания запроса, Request
Timeout .....................................62
10.4.10 409 Конфликт, Conflict .........................62
10.4.11 410 Удален, Gone ...............................62
10.4.12 411 Требуется длина, Length Required ...........63
10.4.13 412 Предусловие неверно, Precondition Failed ...63
10.4.14 413 Объект запроса слишком большой, Request
Entity Too Large ...........................63
10.4.15 414 URI запроса слишком длинный, Request-URI
Too Long ...................................63
10.4.16 415 Неподдерживаемый медиа тип, Unsupported
Media Type .................................63
10.5 5xx - Коды ошибок сервера ..........................64
10.5.1 500 Внутренняя ошибка сервера, Internal Server
Error .......................................64
10.5.2 501 Не реализовано, Not Implemented .............64
10.5.3 502 Ошибка шлюза, Bad Gateway ...................64
10.5.4 503 Сервис недоступен, Service Unavailable ......64
10.5.5 504 Истекло время ожидания от шлюза, Gateway
Timeout .....................................64
10.5.6 505 Не поддерживаемая версия HTTP, HTTP Version
Not Supported ...............................65
11 Установление подлинности доступа (Access
Authentication) .......................................65
11.1 Базовая схема установления подлинности (Basic
Authentication Scheme) .............................66
11.2 Обзорная схема установления подлинности (Digest
Authentication Scheme) .............................67
12 Обсуждение содержимого (Content Negotiation) ..........67
12.1 Управляемое сервером обсуждение ....................68
12.2 Управляемое агентом обсуждение .....................69
12.3 Прозрачное обсуждение ..............................70
13 Кэширование в HTTP ....................................70
13.1.1 Правильность кэширования ........................72
13.1.2 Предупреждения ..................................73
13.1.3 Механизмы управления кэшем ......................74
13.1.4 Явные предупреждения User Agent .................74
13.1.5 Исключения из правил и предупреждений ...........75
13.1.6 Контроллируемое клиентом поведение ..............75
13.2 Модель устаревания .................................75
13.2.1 Устаревание, определеяемое сервером .............75
13.2.2 Эвристическое устаревание .......................76
13.2.3 Вычисление возраста .............................77
13.2.4 Вычисление устаревание ..........................79
13.2.5 Значения однозначного устаревания ...............80
13.2.6 Disambiguating Multiple Responses ...............80
13.3 Модель сравнения (validation model) ................81
13.3.1 Даты последнего изменения (Last-modified Dates)..82
13.3.2 Объектные отметки сравнения кэша ................82
13.3.3 Слабое и сильное сравнение ......................82
13.3.4 Правила когда использовать объектные отметки
(Entity Tags) и даты последнего изменения (Last-
modified Dates).........................................85
13.3.5 Непроверяемые условия ...........................86
13.4 Cachability ответа .................................86
13.5 Построение ответов из кэшей ........................87
13.5.1 Сквозные (End-to-end) и промежуточные (Hop-by-hop)
заголовки ..............................................88
13.5.2 Немодифицируемые заголовки ......................88
13.5.3 Объединение заголовков ..........................89
13.5.4 Объединнение диапазонов байтов ..................90
13.6 Кэширование переговорных ответов (Negotiated
Responses)...............................................90
13.7 Общедоступные и необщедоступные кэши ...............91
13.8 Поведение кеша при ошибочных или незавершенных
ответах .................................................91
13.9 Побочные эффекты GET и HEAD ........................92
13.10 Ошибки после модификаций или стирания .............92
13.11 Write-Through Mandatory ...........................93
13.12 Замена кэша .......................................93
13.13 Списки history ....................................93
14 Определения полей заголовка ...........................94
14.1 Accept .............................................95
14.2 Accept-Charset .....................................97
14.3 Accept-Encoding ....................................97
14.4 Accept-Language ....................................98
14.5 Accept-Ranges ......................................99
14.6 Age ................................................99
14.7 Allow .............................................100
14.8 Authorization .....................................100
14.9 Cache-Control .....................................101
14.9.1 Что кэшируемо (Cachable) .......................103
14.9.2 Что может быть сохранено кэшем .................103
14.9.3 Модификации основного механизма устаревания ....104
14.9.4 Перепроверки правильности кэша и средства
управления перезагрузкой ..............................105
14.9.5 Директива No-Transform .........................107
14.9.6 Расширения средств управления кэшем ............108
14.10 Connection .......................................109
14.11 Content-Base .....................................109
14.12 Content-Encoding .................................110
14.13 Content-Language .................................110
14.14 Content-Length ...................................111
14.15 Content-Location .................................112
14.16 Content-MD5 ......................................113
14.17 Content-Range ....................................114
14.18 Content-Type .....................................116
14.19 Date .............................................116
14.20 ETag .............................................117
14.21 Expires ..........................................117
14.22 From .............................................118
14.23 Host .............................................119
14.24 If-Modified-Since ................................119
14.25 If-Match .........................................121
14.26 If-None-Match ....................................122
14.27 If-Range .........................................123
14.28 If-Unmodified-Since ..............................124
14.29 Last-Modified ....................................124
14.30 Location .........................................125
14.31 Max-Forwards .....................................125
14.32 Pragma ...........................................126
14.33 Proxy-Authenticate ...............................127
14.34 Proxy-Authorization ..............................127
14.35 Public ...........................................127
14.36 Range ............................................128
14.36.1 Диапазоны байт (byte ranges) ..................128
14.36.2 Запросы диапазонов (Range Retrieval
Requests) .............................................130
14.37 Referer ..........................................131
14.38 Retry-After ......................................131
14.39 Server ...........................................132
14.40 Transfer-Encoding ................................132
14.41 Upgrade ..........................................132
14.42 User-Agent .......................................134
14.43 Vary .............................................134
14.44 Via ..............................................135
14.45 Warning ..........................................137
14.46 WWW-Authenticate .................................139
15 Положения о защите ...................................139
15.1 Установления подлинности клиентов .................139
15.2 Предложение выбрать схему установления
подлинности.............................................140
15.3 Неправильное обращение с информацией файла
регистрации сервера (Log)...............................141
15.4 Передача чувствительной (sensitive) информации ....141
15.5 Атаки, основанные именах файлов и путей............142
15.6 Персональная информация ...........................143
15.7 Проблемы секретности, связанные с Accept
заголовками ............................................143
15.8 Подмена DNS-адресов (DNS Spoofing).................144
15.9 Расположение заголовков и Spoofing ................144
16 Подтверждения ........................................144
17 Ссылки ...............................................146
18 Адреса авторов .......................................149
19 Приложения ...........................................150
19.1 Медиа тип Интернет message/http ...................150
19.2 Медиа тип Интернет multipart/byteranges ...........150
19.3 Допустимые приложения .............................151
19.4 Различия между HTTP объектами и MIME объектами ....152
19.4.1 Преобразование к канонической форме ............152
19.4.2 Преобразование форматов дат ....................153
19.4.3 Введение Content-Encoding ......................153
19.4.4 Никакого Content-Transfer-Encoding .............153
19.4.5 Поля HTTP заголовка в Multipart Body-Parts .....153
19.4.6 Введение Transfer-Encoding .....................154
19.4.7 Версия MIME ....................................154
19.5 Изменения после HTTP/1.0 ..........................154
19.5.1 Изменения упрощаущие много-homed сервера и
сохраняющие IP адреса .................................155
19.6 Дополнительные возможности ........................156
19.6.1 Дополнительные методы запросов .................156
19.6.2 Дополнительные определения полей заголовка .....156
19.7 Совместимость с предыдущими версиями ..............160
19.7.1 Совместимость с постоянными соединениями,
определяемыми HTTP/1.0 ...............................161
1 Введение.
1.1 Цель.
Протокол передачи Гипертекста (HTTP) - протокол прикладного уровня
для распределенных, совместных, многосредных информационных систем. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Первой
версией HTTP, известной как HTTP/0.9, был простой протокол для
передачи необработанных данных через Интернет. HTTP/1.0, как
определено в RFC 1945 [6], был улучшением этого протокола, позволяя
сообщениям иметь MIME-подобный формат, содержащий метаинформацию о
передаваемых данных и имел модифицированную семантику
запросов/ответов. Однако, HTTP/1.0 недостаточно хорошо учитывал
особенности работы с иерархическими прокси-серверами (hierarchical
proxies), кэшированием, постоянными соединениями, и виртуальными
хостами (virtual hosts). Кроме того, быстрое увеличение не полностью
совместимых приложений, называющих тот протокол, который они
использовали "HTTP/1.0", потребовало введения версии протокола, в
которой были бы заложены возможности, позволяющие приложениям
определять истинные возможности друг друга.
Эта спецификация определяет протокол "HTTP/1.1". Этот протокол
содержит более строгие требования, чем HTTP/1.0, гарантирующие
надежную реализацию возможностей.
Практически информационные системы требуют большей функциональности,
чем просто загрузку информации, включая поиск, модификацию при
помощи внешнего интерфейса, и аннотацию (annotation). HTTP
предоставляет открытый набор методов, которые указывают цель запроса.
Они основаны на дисциплине ссылки, обеспеченной Универсальным
Идентификатором Ресурса (URI) [3][20], как расположение (URL) [4]
или имя (URN), для идентификации ресурса, к которому этот метод
применяется. Сообщения передаются в формате, подобном используемому
электронной почтой, как определено Многоцелевыми Расширениями
Электронной Почты (MIME).
HTTP также используется как обобщенный протокол связи между агентами
пользователей и прокси-серверами/шлюзами (proxies/gateways) или
другими сервисами Интернета, включая такие, как SMTP [16], NNTP [13],
FTP [18], Gopher [2], и WAIS [10]. Таким образом, HTTP закладывает
основы многосредного (hypermedia) доступа к ресурсам для
разнообразных приложений.
1.2 Требования.
Эта спецификация использует те же самые слова для определения
требований к реализации протокола, что и RFC 1123 [8]. Эти слова
следующие:
НЕОБХОДИМО, ДОЛЖЕН (MUST)
Применяется для указания, что данное требование спецификации
необходимо обеспечить в любом случае.
РЕКОМЕНДУЕТСЯ, СЛЕДУЕТ (SHOULD)
Используется для указания, что данное требование спецификации
должно быть обеспечено, если этому не препятствуют серьезные
причины.
ВОЗМОЖНО, МОЖЕТ (MAY)
Используется для указания, что данное требование спецификации
является опциональным и может быть либо реализовано, либо нет -
по необходимости.
Реализация считается несовместимой, если нарушено хотя бы одно
НЕОБХОДИМЫХ требований спецификации протокола. Реализация,
удовлетворяющая всем НЕОБХОДИМЫМ и РЕКОМЕНДУЕМЫМ тредованиям
называется полностью совместимой, а удовлетворяющая всем НЕОБХОДИМЫМ,
но не всем РЕКОМЕНДУЕМЫМ требованиям называется условно совместимой.
1.3 Терминология.
Эта спецификация использует ряд терминов для описания роли
участников, некоторых объектов, и HTTP связи.
Соединение (connection)
Виртуальный канал транспортого уровня, установленный между двумя
программами с целью связи.
Сообщение (message)
Основной модуль HTTP связи, состоящей из структурной
последовательности октетов, соответствующих синтаксису,
определенному в разделе 4 и передаваемых по соединению.
Ответ (response)
Любое HTTP сообщение, содержащее ответ, определяемый в разделе 5.
Ресурс (resource)
Сетевой объект данных или сервис, который может быть
идентифицирован URI, определеляемым в разделе 3.2. Ресурсы могут
быть доступны в нескольких представлениях (например на нескольких
языках, в разных форматах данных, иметь различный размер, иметь
различную разрешающую способность) или различаться по другим
параметрам.
Объект (entity)
Информация, передаваемая в качестве полезной нагрузки запроса или
ответа. Объект состоит из метаинформации в форме полей заголовка
объекта и содержания в форме тела объекта, как описано в разделе
7.
Представление (representation)
Объект включенный в ответ, и подчиняющийся обсуждению
содержимого (Content Negotiation), что описано в разделе 12.
Может существовать несколько представлений, связанных со
специфическими состояниями ответа.
Обсуждение содержимого (content negotiation)
Механизм для выбора соответствующего представления во время
обслуживания запроса, как описано в разделе 12. Представление
объектов в любом ответе может быть обсуждено (включая ошибочные
ответы).
Вариант (variant)
Ресурс может иметь одно, или несколько представлений, связанных
с ним в данный момент. Каждое из этих представлений называется
"вариант". Использование термина "вариант" не обязательно
подразумевает, что ресурс подчинен обсуждению содержимого.
Клиент (client)
Программа, которая устанавливает соединения с целью посылки
запросов.
Агент пользователя (user agent)
Клиент, который инициирует запрос. Как правило браузеры,
редакторы, роботы (spiders), или другие инструментальные
средства пользователя.
Сервер (server)
Приложение, которое слушает соединения, принимает запросы на
обслуживание и посылает ответы. Любая такая программа способна
быть как клиентом, так и сервером; наше использование данного
термина относится скорее к роли, которую программа выполняет,
создавая специфические соединения, нежели к возможностям
программы вообще. Аналогично, любой сервер может действовать как
первоначальный сервер, прокси-сервер, шлюз, или туннель (tunnel),
изменяя поведение, основываясь на характере каждого запроса.
Первоначальный сервер (origin server)
Сервер, на котором данный ресурс постоянно находится или должен
быть создан.
Прокси-сервер (proxy)
Программа-посредник, которая действует и как сервер, и как
клиент с целью создания запросов от имени других клиентов.
Запросы обслуживаются прокси-сервером, или передаются им,
возможно с изменениями. Прокси-сервер должен удовлетворять
требованиям клиента и сервера, согласно этой спецификации.
Шлюз (gateway)
Сервер, который действует как посредник для некоторого
другого сервера. В отличие от прокси-сервера, шлюз получает
запросы в качестве первоначального сервера для запрошенного
ресурса; клиент запроса может не знать, что он соединяется со
шлюзом.
Туннель (tunnel)
Программа-посредник, которая поддерживает соединение. Один
раз созданный, туннель не рассматривается как часть HTTP связи,
хотя туннель, возможно, был инициализирован запросом HTTP.
Туннель прекращает существовать, когда оба конца соединения
закрываются.
Кэш (cache)
Локальная память, в которой программа хранит сообщения ответов,
и в которой располагается подсистема, управляющая хранением,
поиском и стиранием сообщений. Кэш сохраняет ответы, которые
могут быть сохранены, чтобы уменьшить время ответа и загрузку
сети (траффик) при будущих эквивалентных запросах. Любой клиент
или сервер может иметь кэш, но кэш не может использоваться
сервером, который действует как туннель.
Кэшируемый (cachable)
Ответ является кэшируемым, если кэшу разрешено сохранить копию
ответного сообщения для использования при ответе на последующие
запросы. Правила для определения кэшируемости HTTP ответов
определены в разделе 13. Даже если ресурс кэшируем, могут
существовать дополнительные ограничения на использование кэшем
сохраненной копии для сходного запроса.
Непосредственный (first-hand)
Ответ считается непосредственным, если он приходит
непосредственно от первоначального сервера без ненужной задержки,
возможно через один или несколько прокси-серверов. Ответ также
является непосредственным, если его правильность только что была
проверена непосредственно первоначальным сервером.
Точное время устаревания (explicit expiration time)
Время, определенное первоначальным сервером и показывающее кэшу,
когда объект больше не может быть возвращен кэшем клиенту без
дополнительной проверки правильности.
Эвристическое время устаревания (heuristic expiration time)
Время устаревания, назначенное кэшем, если не указано точное
время устаревания.
Возраст (age)
Возраст ответа - время, прошедшее с момента отсылки, или
успешной проверки ответа первоначальным сервером.
Время жизни (freshness lifetime)
Отрезок времени между порождением ответа и временем устаревания.
Свежий (fresh)
Ответ считается свежим, если его возраст еще не превысил время
жизни.
Просроченнный (stale)
Ответ считается просроченным, если его возраст превысил время
жизни.
Семантически прозрачный (semantically transparent)
Говорят, что кэш ведет себя "семантически прозрачным" образом в
отношении специфического ответа, когда использование кэша не
влияет ни на клиента запроса, ни на первоначальный сервер, но
повышает эффективность. Когда кэш семантически прозрачен, клиент
получает точно такой же ответ (за исключением промежуточных
(hop-by-hop) заголовков), который получил бы, запрашивая
непосредственно первоначальный сервер, а не кэш.
? Указатель правильности (validator)
Элемент протокола (например, метка объекта или время последней
модификации (Last-Modified time)), который используется, чтобы
выяснить, является ли находящаяся в кэше копия эквивалентом
объекта.
1.4 Общее описание.
Протокол HTTP - это протокол запросов/ответов. Клиент посылает
серверу запрос, содержащий метод запроса, URI, версию протокола,
MIME-подобное сообщение, содержащее модификаторы запроса, клиентскую
информацию, и, возможно, тело запроса, по соединению. Сервер
отвечает строкой состояния, включающей версию протокола сообщения,
код успешного выполнения или код ошибки, MIME-подобное сообщение,
содержащее информацию о сервере, метаинформацию объекта, и,
возможно, тело объекта. Связь между HTTP и MIME описана в приложении
19.4.
Большинство HTTP соединений инициализируется агентом пользователя и
состоит из запроса, который нужно применить к ресурсу на некотором
первоначальном сервере. В самом простом случае, он может быть
выполнен посредством одиночного соединения (v) между агентом
пользователя (UA) и первоначальным сервером (O).
цепочка запросов --------------------->
UA -------------------v------------------- O
<----------------------- цепочка ответов
Более сложная ситуация возникает, когда в цепочке запросов/ответов
присутствует один или несколько посредников. Существуют три
основных разновидности посредников: прокси-сервера, шлюзы, и
туннели. Прокси-сервер является агентом-посредником, который
получает запросы на некоторый URI в абсолютной форме, изменяет все
сообщение или его часть, и отсылает измененный запрос серверу,
идентифицированному URI. Шлюз - это принимающий агент, действующий
как бы уровень выше некоторого другого сервера(ов) и, в случае
необходимости, транслирующий запросы в протокол основного сервера.
Туннель действует как реле между двумя соединениями не изменяя
сообщения; туннели используются, когда связь нужно производить
через посредника (например Firewall), который не понимает
содержание сообщений.
цепочка запросов ----------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------ цепочка ответов
На последнем рисунке показаны три посредника (A, B, и C) между
агентом пользователя и первоначальным сервером. Запросы и ответы
передаются через четыре отдельных соединения. Это различие важно,
так как некоторые опции HTTP соединения применимы только к
соединению с ближайшим не туннельным соседом, некоторые только к
конечным точкам цепочки, а некоторые ко всем соединениям в цепочке.
Хотя диаграмма линейна, каждый участник может быть задействован в
нескольких соединениях одновременно. Например, B может получать
запросы от других клиентов, а не только от A, и/или пересылать
запросы к серверам, отличным от C, в то же время, когда он
обрабатывает запрос от А.
Любая сторона соединения, которая не действует как туннель, может
использовать внутренний кэш для обработки запросов. Эффект кэша
заключается в том, что цепочка запросов/ответов сокращается, если
один из участников в цепочке имеет кэшированный ответ, применимый
к данному запросу. Далее иллюстрируется цепочка, возникающая в
результате того, что B имеет кэшированую копию раннего ответа O
(полеченного через C) для запроса, и который не кэшировался ни UA,
ни A.
цепочка запросов ------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<-------- цепочка ответов
Не все ответы полезно кэшировать, а некоторые запросы могут
содержать модификаторы, которые включают специальные требования,
управляющие поведением кэша. Требования HTTP для поведения кэша в
отношении кэшируемых ответов определены в разделе 13.
Фактически, имеется широкое разнообразие архитектур и конфигураций
кэшей и прокси-серверов, в настоящее время разрабатываемых или
развернутых в World Wide Web; эти системы включают национальные
иерархии прокси-кэшей, которые сохраняют пропускную способность
межокеанских каналов, системы, которые распространяют во много
мест содержимое кэша, организации, которые распространяют
подмножества кэшируемых данных на CD-ROM, и так далее. HTTP системы
используются в корпоративных интранет-сетях с высокоскоростными
линиями связи, и для доступа через PDA с маломощными линиями и
неустойчивой связи. Цель HTTP/1.1 состоит в поддержании широкого
многообразия конфигураций, уже построенных при введении ранних
версий протокола, а также в удовлетворении потребностей
разработчиков web приложений, требующих высокой надежности, по
крайней мере надежных относительно индикации отказа.
HTTP соединение обычно происходит посредством TCP/IP соединений.
Заданный по умолчанию порт TCP - 80, но могут использоваться и
другие порты. HTTP также может быть реализован посредством любого
другого протокола Интернета, или других сетей. HTTP необходима
только надежная передача данных, следовательно может использоваться
любой протокол, который гарантирует надежную передачу данных;
отображение структуры запроса и ответа HTTP/1.1 на транспортные
модули данных рассматриваемого протокола - вопрос, не решаемый
этой спецификацией.
Большинство реализаций HTTP/1.0 использовало новое соединение для
каждого обмена запросом/ответом. В HTTP/1.1, установленное
соединение может использоваться для одного или нескольких обменов
запросом/ответом, хотя соединение может быть закрыто по ряду
причин (смотрите раздел 8.1).
2 Письменные соглашения и обобщенная грамматика.
2.1 Увеличенная нормальная запись Бекуса-Наура (BNF).
Все механизмы, определенные этим документом, описаны как в обычной,
так и в увеличенной нормальной записи Бекуса-Наура (BNF), подобной
используемой в RFC 822 [9]. Разработчик должен быть знаком с такой
формой записи, чтобы понять данную спецификацию. Увеличенная
нормальная запись Бекуса-Наура включает следующие конструкции:
имя = определение
name = definition
Имя правила - это просто его название (не включающее символов
"<" и ">"), и отделяемое от определения символом равенства "=".
Пробел важен только при выравнивании продолжающихся строк,
используемых для указания определений правил, которые
занимают более одной строки. Некоторые основные правила, такие
как SP, LWS, HT, CRLF, DIGIT, ALPHA и т.д, представлены в
верхнем регистре. Угловые скобки используются в определении
всякий раз, когда их присутствие облегчает использование имен
правил.
"литерал"
"literal"
Кавычки окружают литеральный текст. Если не установлено иного,
этот текст регистро-независим.
правило1 | правило2
rule1 | rule2
Элементы, отделяемые полосой ("|") являются вариантами. Например,
"да | нет" принимает значение либо да, либо нет.
(правило1 правило2)
(rule1 rule2)
Элементы, включенные в круглые скобки обрабатываются как
один элемент. Таким образом, "(elem (foo | bar) elem)"
допускает последовательности лексем "elem foo elem" и
"elem bar elem".
*правило
*rule
Символ "*", предшествующий элементу, указывает повторение.
Полная форма - "<n>*<m>element" означает минимум <n>, максимум
<m> вхождений элемента. Значения по умолчанию - 0 и
бесконечность. Таким образом запись "*(element)" допускает
любое число повторений (в том числе ноль); запись "1*element"
требует по крайней мере одно повторение; а "1*2element"
допускает либо один, либо два повторения.
N правило
N rule
Точное количество повторений: "<n>(element)" эквивалентно
"<n>*<n>(element)"; то есть присутствует точно <n> повторов
элемента. Таким образом 2DIGIT - номер из 2 цифр, а 3ALPHA
- строка из трех алфавитных символов.
#правило
#rule
Конструкция "#" предназначена, подобно "*", для определения
списка элементов. Полная форма - "<n>#<m>element" означает
минимум <n>, максимум <m> вхождений элемента, отделенных одной
или несколькими запятыми (","), и, возможно, линейным пробелом
(LWS). Это обычно делает форму списков очень простой; правило
типа "( *LWS element *( *LWS "," *LWS element)) " можно
представить как "1#элемент". Везде, где используется эта
конструкция, пустые элементы допускаются, но не учитываются при
подсчете представленных элементов. То есть конструкция
"(element), , (element)" допускается, но считаются в ней только
два элемента. Следовательно там, где требуется по крайней мере
один элемент, должен присутствовать по крайней мере один не
пустой элемент. Значения по умолчанию - 0 и бесконечность.
Таким образом запись "#(element)" допускает любое число
повторений (в том числе ноль); запись "1#element" требует по
крайней мере одного повтора ненулевого элемента; а "1*2element"
допускает один или два повтора.
; комментарий
; comment
Точка с запятой, поставленная справа от текста правила, начинает
комментарий, который продолжается до конца строки. Это - простой
способ включения полезных пометок параллельно спецификациям.
подразумевая *LWS
implied *LWS
Грамматика, описанная этой спецификацией основана на словах.
За исключением случаев, в которых отмечено иное, линейный
пробел (LWS) может быть включен между любыми двумя смежными
словами (лексемой или строкой цитирования), и между смежными
лексемами и разделителями (tspecials), не изменяя интерпретацию
поля. Между любыми двумя лексемами должен существовать по
крайней мере один разделитель (tspecials), так как иначе они
интерпретируются как одна лексема.
2.2 Основные правила.
Следующие правила используются в продолжение всей этой спецификации
для описания основных конструкций синтаксического анализа.
Кодированный набор символов US-ASCII определен в ANSI X3.4-1986
[21].
HTTP/1.1 определяет последовательность CR LF как метку конца строки
во всех элементах протокола, за исключением тела объекта (смотрите
приложение 19.3 о допустимых применениях (tolerant applications)).
Метка конца строки внутри тела объекта определяется соответствыющим
медиа типом, как описано в разделе 3.7.
CRLF = CR LF
HTTP/1.1 заголовки занимают несколько строк, если следующая строка
начинается с пробела или метки горизонтальной табуляции. Все
незаполненное пространство строки, включая переход на следующую
строку, имеет ту же семантику, что и SP.
LWS = [CRLF] 1*( SP | HT )
Правило TEXT используется только для описательного содержимого поля
и значений, которые не предназначены, для интерпретации
синтаксическим анализатором сообщений. Слова *TEXT могут содержать
символы из наборов символов (character sets), отличных от
ISO 8859-1 [22], только когда они закодированы согласно правилам
RFC 1522 [14].
TEXT = <любой OCTET, за исключением CTLs,
но содержащий LWS>
Шестнадцатеричные цифры используются некоторыми элементами
протокола.
Многие значения полей заголовка HTTP/1.1 состоят из слов,
разделенных LWS или специальными символами. Эти специальные символы
ДОЛЖНЫ находиться в цитируемой строке (quoted string), чтобы быть
использованными в качестве значения параметра.
token = 1*<любой CHAR за исключением CTLs или
tspecials>
В некоторые поля HTTP заголовка могут быть включены комментарии.
Текст комментария окружается круглыми скобками. Комментарии
допускаются только в полях, содержащих "comment" как часть
определения значения поля. Во всех других полях круглые скобки
рассматриваются частью значения поля.
comment = "(" *( ctext | comment ) ")"
ctext = <любой TEXT не включающий "(" and ")">
Строка текста анализируется как одно слово, если это цитирование,
помеченное двойными кавычками.
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <любой TEXT не включающий <">>
Символ наклонной черты влево ("\") может использоваться как
односимвольный механизм цитирования только внутри конструкций
комментария и строки цитирования (quoted-string).
quoted-pair = "\" CHAR
3 Параметры протокола.
3.1 Версия HTTP.
HTTP использует схему нумерации типа "<major>.<minor>", для указания
версии протокола. Стратегия версификации протокола предназначена
для того, чтобы позволить отправителю указать формат сообщения и
свои способности понимания для дальнейшей HTTP связи, прежде чем
он получит что-либо посредством этой связи. При добавлении
компонентов сообщения, которые не воздействуют на поведение
связи, или компонентов, которые добавляются только к расширяемым
значениям поля, номер версии не меняется. Когда внесенные в протокол
изменения добавляют возможности, которые не изменяют общий алгоритм
анализа сообщений, но которые расширяют семантику сообщения и
подразумевают дополнительные возможности отправителя, увеличивается
<Minor> номер. Когда формат сообщения протокола изменяется
увеличивается <Major> номер.
Версия HTTP сообщения обозначается полем HTTP-version в первой
строке сообщения.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Обратите внимание, что major и minor числа ДОЛЖНЫ обрабатываться
как отдельные целые числа и что каждое может состоять более чем из
одной цифры. Таким образом, HTTP/2.4 - более низкая версия, чем
HTTP/2.13, которая в свою очередь ниже чем HTTP/12.3. Нули ДОЛЖНЫ
игнорироваться получателями и НЕ ДОЛЖНЫ посылаться.
Приложения, посылающие сообщения запросов или ответов, которые
описывает эта спецификация, ДОЛЖНЫ включить HTTP версию
(HTTP-version) "HTTP/1.1". Использование этого номера версии
указывает, что посылающее приложение по крайней мере условно
совместимо с этой спецификацией.
HTTP версия приложения - это самая высокая HTTP версия, для которой
приложение является по крайней мере условно совместимым.
Приложения, реализующие прокси-сервера и шлюзы, должны быть
внимательны, когда пересылают сообщения протокола различных версий.
Начиная с момента, когда версия протокола указывает возможности
отправителя, прокси-сервер/шлюз никогда НЕ ДОЛЖЕН посылать
сообщения, версия которых больше, чем HTTP версия отправителя; если
получена более высокая версия запроса, то прокси-сервер/шлюз ДОЛЖЕН
или понизить версию запроса, отдав сообщение об ошибке, или
переключиться на туннельное поведение. У запросов, версия которых
ниже, чем HTTP версия прокси-сервера/шлюза МОЖНО перед пересылкой
увеличить версию; ответ прокси-сервера/шлюза на этот запрос ДОЛЖЕН
иметь ту же самую major версию, что и запрос.
Обратите внимание: Преобразование версий HTTP может включать
модификацию полей заголовка, требуемых или запрещенных в этих
версиях.
3.2 Универсальные Идентификаторы Ресурсов (URI).
URI известны под многими именами: WWW адреса, Универсальные
Идентификаторы Документов, Универсальные Идентификаторы Ресурсов
(URI), и, в заключение, как комбинация Единообразных Идентификаторов
Ресурса (Uniform Resource Locators, URL) и Единообразных Имен
Ресурса (Uniform Resource Names, URN). HTTP определяет URL просто
как строку определенного формата, которая идентифицирует - через
имя, расположение, или любую другую характеристику - ресурс.
3.2.1 Общий синтаксис.
URI в HTTP могут представляться в абсолютной (absolute) форме или
относительно некоторой известной основы URI (relative), в
зависимости от контекста их использования. Эти две формы
различаются тем, что абсолютные URI всегда начинаются с имени
схемы с двоеточием.
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
Полную информацию относительно синтаксиса и семантики URL смотрите
RFC 1738 [4] И RFC 1808 [11]. Вышеуказанная нормальная запись
Бекуса-Наура включает национальные символы, недозволенные в
допустимых URL (это определено в RFC 1738), так как HTTP серверы
позволяют использовать для представления части rel_path адресов
набор незарезервированных символов, и, следовательно, HTTP
прокси-сервера могут получать запросы URI, не соответствующие
RFC 1738.
Протокол HTTP не накладывает a priori никаких ограничений на длины
URI. Серверы ДОЛЖНЫ быть способны обработать URI любого ресурса,
который они обслуживают, и им СЛЕДУЕТ быть в состоянии обрабатывать
URI неограниченной длины, если они обслуживают формы, основанные
на методе GET, которые могут генерировать такой URI. Серверу
СЛЕДУЕТ возвращать код состояния 414 (URI запроса слишком длинный,
Request-URI Too Long), если URI больше, чем сервер может обработать
(смотрите раздел 10.4.15).
Обратите внимание: Серверы должны быть осторожны с URI, которые
имеют длину более 255 байтов, потому что некоторые старые
клиенты или прокси-сервера не могут правильно поддерживать
эти длины.
3.2.2 HTTP URL.
"Http" схема используется для доступа к сетевым ресурсам при помощи
протокола HTTP. Этот раздел определяет схемо-определенный синтаксис
и семантику для HTTP URL.
host = <допустимое доменное имя машины
или IP адрес (в точечно-десятичной форме),
как определено в разделе 2.1 RFC 1123>
port = *DIGIT
Если порт пуст или не задан - используется порт 80. Это означает,
что идентифицированный ресурс размещен в сервере, ожидающем TCP
соединений на специфицированном порте port, компьютера host, и
запрашиваемый URI ресурса - abs_path. Использования IP адресов в URL СЛЕДУЕТ избегать, когда это возможно (смотрите RFC 1900 [24]).
Если abs_path не представлен в URL, он ДОЛЖЕН рассматриваться как
"/" при вычислении запрашиваемого URI (Request-URI) ресурса
(раздел 5.1.2).
3.2.3 Сравнение URI.
При сравнении двух URI, чтобы решить соответствуют ли они друг
другу или нет, клиенту СЛЕДУЕТ использовать чувствительное к
регистру пооктетное (octet-by-octet) сравнение этих URI, со
следующими исключениями:
o Порт, который пуст или не указан, эквивалентен заданному по
умолчанию порту для этого URI;
o Сравнение имен хостов ДОЛЖНО производиться без учета регистра;
o Сравнение имен схем ДОЛЖНО производиться без учета регистра;
o Пустой abs_path эквивалентен "/".
Символы, отличные от тех, что находятся в "зарезервированных"
("reserved") и "опасных" ("unsafe") наборах (см. раздел 3.2)
эквивалентны их кодированию как ""%" HEX HEX ".
HTTP приложения исторически допускали три различных формата для
представления даты/времени:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, дополненный в RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, переписанный как RFC 1036
Sun Nov 6 08:49:37 1994 ; формат asctime() ANSI C
Первый формат выбран в качестве стандарта Интернета и представляет
подмножество фиксированной длины, как определено в RFC 1123
(модифицированном RFC 822). Второй формат находится в общем
пользовании, но основан на устаревшем и потерявшем статус стандарта
RFC 850 [12], описывающем форматы дат, он обладает тем недостатком,
что год указывается не в четырехразрядной нотации. Клиенты и
серверы HTTP/1.1, которые анализируют значение даты, ДОЛЖНЫ
понимать все три формата (для совместимости с HTTP/1.0), но
генерировать для представления значений дат в полях заголовка HTTP
ДОЛЖНЫ только формат RFC 1123 .
Обратите внимание: Поощряется практика, при которой получатели
значений дат здраво воспринимают значения дат, которые, возможно,
посланы не HTTP приложениями, что имеет место при загрузке или
регистрации сообщений через прокси-сервера/шлюзы к SMTP или NNTP.
Все без исключений форматы HTTP даты/времени ДОЛЖНЫ быть
представлены в Greenwich Mean Time (GMT). В первых двух форматах
данный факт указывается включением трехсимвольного сокращения "GMT"
в качестве часового пояса. В asctime() формате это ДОЛЖНО
подразумеваться при чтении.
Обратите внимание: Эти требования - это требования к для
форматам даты/времени, которые применяются внутри потока
протокола HTTP. Клиентам и серверам не требуется использовать
эти форматы для представления пользователю, регистрации
запросов и т.д.
3.3.2 Разность секунд (delta seconds).
Некоторые поля HTTP заголовка позволяют указывать значения времени
в виде целого числа секунд, представленного в десятичной форме,
которые должны пройти с того момента, как сообщение было получено.
delta-seconds = 1*DIGIT
3.4 Кодовые таблицы (character sets).
HTTP использует то же самое определение термина "кодовая таблица",
которое описано для MIME:
Термин "кодовая таблица" используется в данном документе, чтобы
сослаться на метод, использующий одну или несколько таблиц для
преобразования последовательности октетов в последовательность
символов. Стоит отметить, что однозначное преобразование в
обратном направлении не требуется, и что не все символы могут
быть доступны в данной кодовой таблице, и что кодовая таблица
может обеспечивать более чем одну последовательность октетов для
представления специфических символов. Это определение допускает
различные виды кодирования символов, от простых однотабличных
отображений типа US-ASCII до сложных методов, переключающих
таблицы, наподобие тех, которые используют методики ISO 2022.
Однако определение, связанное с именем кодовой таблицы MIME
ДОЛЖНО полностью определять отображение, которое преобразует
октеты в символы. В частности использование внешней информации
профилирования для определения точного отображения не
разрешается.
Обратите внимание: Это использование термина "кодовая таблица"
обычно упоминается как "кодирование символов". Однако, с тех пор
как HTTP и MIME совместно используют одиннаковую запись, важно,
чтобы совпадала также и терминология.
Кодовые таблицы HTTP идентифицируются лексемами, не чувствительными
к регистру. Полный набор лексем определен реестром кодовых таблиц
IANA [19].
charset = token
Хотя HTTP позволяет использовать в качестве значения charset
произвольную лексему, любая лексема, которая имеет предопределенное
значение в реестре кодовых таблиц IANA, ДОЛЖНА представлять набор
символов, определенный в данном реестре. Приложениям СЛЕДУЕТ
ограничить использование символьных наборов теми, которые
определены в реестре IANA.
3.5 Кодирование содержимого (content codings).
Значение кодирования содержимого указывает какое преобразование
кодирования было или будет применено к объекту. Кодирование
содержимого используется прежде всего для сжатия или другого
полезного преобразования к документу без потери идентификации
основного медиа типа и информации. Часто, объект сохраняется в
кодированной форме, затем передается, а потом декодируется
получателем.
content-coding = token
Все значения кодирования содержимого (content-coding) не
чувствительны к регистру. HTTP/1.1 использует значения кодирования
содержимого (content-coding) в полях заголовка Accept-Encoding
(раздел 14.3) и Content-Encoding (раздел 14.12). Хотя значение
описывает кодирование содержимого, но, что более важно - оно
указывает, какой механизм декодирования потребуется для обратного
процесса.
Internet Assigned Numbers Authority (IANA) действует как реестр
для значений лексем кодирования содержимого (content-coding).
Первоначально реестр содержал следующие лексемы:
gzip
Формат кодирования, производящий сжатие файла программой "gzip"
(GNU zip), как описано в RFC 1952 [25]. Это формат Lempel-Ziv
кодирования (LZ77) с 32 разрядным CRC.
compress
Формат кодирования, производимый общей программой "compress" для
сжатия UNIX файлов. Это формат адаптивного Lempel-Ziv-Welch
кодирования (LZW).
Обратите внимание: Использовать названия программ для
идентификации форматов кодирования не желательно и должно быть
не понятно будущим кодированиям. Их использование здесь
объясняется исторической практикой, но так делать не нужно. Для
совместимости с предыдущими реализациями HTTP, приложения должны
рассматривать "x-gzip" и "x-compress" как эквиваленты "gzip" и
"compress" соответственно.
deflate
Формат zlib, определенный в RFC 1950 [31], в комбинации с
механизмом сжатия "deflate", описанным в RFC 1951 [29].
Новая лексема значения кодирования содержимого (content-coding)
должна быть зарегистрирована; чтобы обеспечить взаимодействие между
клиентами и серверами, спецификация алгоритма кодирования
содержимого, необходимого для определения нового значения, должна
быть открыто опубликована и адекватна для независимой реализации,
а также соответствовать цели кодирования содержимого определенного
в этом разделе.
3.6 Кодирование передачи (Transfer Codings).
Значения кодирования передачи используются для указания
преобразования кодирования, которое было или должно быть применено
к телу объекта (entity-body) в целях гарантирования "безопасной
передачи" по сети. Оно отличается от кодирования содержимого тем,
что кодирование передачи - это свойство сообщения, а не
первоначального объекта.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
Все значения кодирования передачи (transfer-coding) не
чувствительны к регистру. HTTP/1.1 использует значения кодирования
передачи (transfer-coding) в поле заголовка Transfer-Encoding
(раздел 14.40).
Кодирования передачи - это аналоги значений
Content-Transfer-Encoding MIME, которые были разработаны для
обеспечения безопасной передачи двоичных данных при использовании
7-битного обслуживания передачи. Однако безопасный транспорт
имеет другое предназначение для чисто 8-битного протокола передачи.
В HTTP единственая опасная характеристика тела сообщения вызвана
сложностью определения точной длины тела сообщения (раздел 7.2.2),
или желанием шифровать данные при пользовании общедоступным
транспортом.
Кодирование по кускам (chunked encoding) изменяет тело сообщения
для передачи его последовательностью кусков, каждый из которых
имеет собственный индикатор размера, сопровождаемым опциональным
завершителем, содержащим поля заголовка объекта. Это позволяет
динамически создаваемому содержимому передаваться вместе с
информацией, необходимой получателю для проверки полноты получения
сообщения.
Кодирование по кускам (chunked encoding) оканчивается куском
нулевого размера, следующим за завершителем, оканчивающимся пустой
строкой. Цель завершителя состоит в эффективном методе обеспечения
информации об объекте, который сгенерирован динамически; приложения
НЕ ДОЛЖНЫ посылать в завершителе поля заголовка, которые явно не
предназначены для использования в завершителе, такие как
Content-MD5 или будущие расширения HTTP для цифровых подписей и
других возможностей.
Примерный процесс декодирования Chunked-Body представлен в
приложении 19.4.6.
Все HTTP/1.1 приложения ДОЛЖНЫ быть в состоянии получать и
декодировать кодирование передачи "по кускам" ("chunked" transfer
coding), и ДОЛЖНЫ игнорировать расширения кодирования передачи,
которые они не понимают. Серверу, который получил тело объекта со
значением кодирования передачи, которое он не понимает, СЛЕДУЕТ
возвратить ответ с кодом 501 (Не реализовано, Not Implemented) и
разорвать соединение. Сервер НЕ ДОЛЖЕН посылать поля кодирования
передачи (transfer-coding) HTTP/1.0 клиентам.
3.7 Медиа типы (Media Types).
HTTP использует Медиа Типы Интернета (Internet Media Types) в полях
заголовка Content-Type (раздел 14.18) и Accept (раздел 14.1) для
обеспечения открытой и расширяемой типизации данных и обсуждения
типов.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Параметры могут следовать за type/subtype в форме пар
атрибут/значение (attribute/value).
parameter = attribute "=" value
attribute = token
value = token | quoted-string
Тип, подтип, и имена атрибутов и параметров не чувствительны к
регистру. Значения параметров могут быть чувствительными к регистру,
но могут быть и не чувствительны, в зависимости от семантики имени
параметра. Линейный пробел (LWS) НЕ ДОЛЖЕН использоваться между
типом и подтипом, между атрибутом и значением. Агенты пользователей,
распознающие медиа типы, ДОЛЖНЫ обрабатывать (или подготавливать
для обработки любыми внешними приложениями) параметры для тех типов
MIME, которые описаны, и сообщать пользователю о обнаруженных
проблемах.
Обратите внимание: Некоторые старые HTTP приложения не распознают
параметры медиа типов. При посылке данных к таким HTTP приложениям
реализации должны использовать параметры медиа типов только когда
это требуется по определению типа/подтипа.
Значения медиа-типов регистрируются Internet Assigned Number
Authority (IANA). Процесс регистрации медиа типа определен в RFC
2048 [17]. Использование не зарегистрированных медиа типов вводит
в заблуждение.
3.7.1 Канонизация и предопределенные значения типа text.
Медиа типы Интернета зарегистрированы в канонической форме. Вообще,
тело объекта, передаваемое HTTP сообщением, ДОЛЖНО быть
представлено в соответствующей каноническиой форме до передачи;
исключение составляют типы "text", определяемые в следующем абзаце.
В канонической форме медиа подтипы типа "text" используют CRLF в
качестве метки конца строки. HTTP ослабляет это требование и
позволяет передавать текст размеченный таким образом, что еденичные
CR или LF могут быть метками конца строки, правда это правило
должно быть выполнено для всего тела объекта (entity-body). HTTP
приложения ДОЛЖНЫ воспринимать CRLF, просто CR, и просто LF как
представление конца строки в текстовых типах, переданных по HTTP.
Кроме того, если текст представляется в кодовой таблице, которая
не использует октеты 13 и 10 для CR и LF соответственно, что имеет
место в некоторых многобайтовых кодовых таблицах, то HTTP позволяет
использовать любые последовательности октетов, определенные этим
набором символов для представления эквивалентов CR и LF в качестве
кода конца строки. Эта гибкость в отношении концов строк применима
только к текстовым типам в теле объекта; просто CR или просто LF НЕ
ДОЛЖНЫ заменять CRLF внутри любой управляющей структуры HTTP (типа
поля заголовка и разделителей типа multipart).
Если тело объекта кодируется при помощи Content-Encoding, то
основные данные ДОЛЖНЫ быть в определенной выше форме до
кодирования.
Параметр "charset" используется с некоторыми медиа типами для
указания кодовой таблицы (раздел 3.4), используемой для
представления данных. Если параметр "charset" не указан
отправителем, то при получении по HTTP медиа подтипы типа "text"
имеют значение "charset", по умолчанию равное "ISO-8859-1". Данные
в кодовых таблицах или их подмножествах, отличных от "ISO-8859-1"
ДОЛЖНЫ быть помечены соответствующим значением "charset".
Некоторое программное обеспечение HTTP/1.0 интерпретировало
заголовок Content-Type без параметра "charset" неправильно, как
означающее "должен предположить получатель". Отправители, желающие
предусмотреть такое поведение МОГУТ включать параметр "charset"
даже когда charset равен ISO-8859-1 и ДОЛЖНЫ сделать это, если
известно, что это не запутает получателя.
К сожалению, некоторые старые HTTP/1.0 клиенты не работали правильно
с определением параметра "charset". HTTP/1.1 получатели ДОЛЖНЫ
отдавать приоритет метке "charset", поставленной отправителем; и те
агенты пользователей, которые имеют возможность "предположить"
charset ДОЛЖНЫ при первоначальном отображении документа использовать
charset из поля content-type, если они поддерживают такой charset,
а затем использовать собственные установки.
3.7.2 Типы Multipart.
MIME предусматривает ряд типов "multipart" - формирующих пакет из
одного или нескольких объектов внутри тела одного сообщения. Все
типы mulptipart используют общий синтаксис, определеный в MIME [7],
и ДОЛЖНЫ содержать разделительный параметр частью значения медиа
типа. Тело сообщения - самостоятельный элемент протокола и,
следовательно, ДОЛЖНО использовать только СRLF для представления
концов строк между частями тела (body-parts). В отличие от MIME,
окончание любого multipart сообщения ДОЛЖНО быть пустым; HTTP
приложения НЕ ДОЛЖНЫ передавать окончание (даже если первоначальный
multipart содержит заключение).
В HTTP части тела (body-parts) типа multipart МОГУТ содержать поля
заголовка, которые являются значащими в примнении к этой части.
Поле заголовка Content-Location (раздел 14.15) СЛЕДУЕТ включать в
часть тела (body-part) каждого включенного объекта, который может
быть идентифицирован URL.
Вообще говоря, HTTP агенту пользователя СЛЕДУЕТ следовать такому же
или подобному поведению, которому следовал бы MIME агент
пользователя после получения типа multipart. Если приложение
получает незарегистрированный подтип multipart, оно ДОЛЖНО
обрабатывать его как подтип "multipart/mixed".
Обратите внимание: тип "multipart/form-data" был специально
определен для передачи данных формы, подходящих для обработки
методом запроса POST, что описано в RFC 1867 [15].
3.8 Лексемы программ (Product Tokens).
Лексемы программ используются, чтобы обеспечить коммуникационным
приложениям возможность идентифицировать себя названием и версией
программного обеспечения. Большинство полей, использующих лексемы
программ также допускает перечисление подпрограмм, которые формируют
значительную часть приложения, и которые перечисляются через пробел.
В соответствии с соглашением, подпрограммы перечисляются в порядке
их значения для идентификации приложения.
Лексемы программ должны быть короткими и по сути - использование их
для рекламы или другой несущественной информации однозначно
запрещено. Хотя в лексеме product-version может встречаться любой
символ, все же ее следует использовать только для идентификатора
версии (то есть, последовательным версиям одной и той же программы
СЛЕДУЕТ иметь отличия только в части product-version лексемы
product.
3.9 Качественные значения (Quality Values).
Обсуждение содержимого HTTP (раздел 12) использует короткие числа "с
плавающей точкой" для указания относительной важности ("веса")
различных оговоренных параметров. Вес - это нормализованое
вещественное число в диапазоне от 0 до 1, где 0 - минимальное, а
1 - максимальное значение. HTTP/1.1 приложения НЕ ДОЛЖНЫ
генерировать более трех цифр после десятичной точки.
Пользовательским конфигурациям этих значений СЛЕДУЕТ также
ограничиваться этим режимом.
"Качественные значения" - не корректное название, так как эти
значения просто представляют отношение снижения производительности
к желательному качеству.
3.10 Метки языков (Language Tags).
Метка языка идентифицирует естественный язык: разговорный,
письменный, или другой используемый людьми для обмена информацмей
с другими людьми. Машинные языки являются исключением. HTTP
использует метки языка внутри полей Accept-Language и
Content-Language.
Синтаксис и запись HTTP меток языка такие же, как определяемые
RFC 1766 [1]. В резюме, метка языка состоит из одной или нескольких
частей: метка первичного языка и, возможно пустой, ряд подчиненных
меток:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Внутри метки не допустим пробел и все метки не чувствительны к
регистру. Пространство имен меток языка управляется IANA. Например
метки содержат:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Любая двухсимвольная первичная метка является меткой аббревеатуры
языка ISO 639, а любая двухсимвольная подчиненная метка является
меткой кода страны ISO 3166. (Последние три метки из
вышеперечисленных - не зарегистрированные метки; все, кроме
последней - примеры меток, которые могли бы быть зарегистрированы
в будущем.)
3.11 Метки объектов (Entity Tags).
Метки объектов используются для сравнения двух или более объектов
от одного и того же запрошенного ресурса. HTTP/1.1 использует метки
объекта в полях заголовка ETag (раздел 14.20), If-Match (раздел
14.25), If-None-Match (раздел 14.26), и If-Range (раздел 14.27).
Определение того, как они используются и сравниваются в качестве
меток проверки кэша находится в разделе 13.3.3. Метка объекта
состоит из непрозрачной цитируемой строки (opaque quoted string),
возможно предваренной индикатором слабости (weakness indicator).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
"Сильная метка объекта" ("strong entity tag") может быть разделена
двумя объектами ресурса, только если они пооктетно эквивалентны.
"Слабая метка объекта" ("weak entity tag"), обозначяемая префиксом
"W/", может быть разделена двумя объектами ресурса только если
объекты эквивалентны и могли бы заменять друг друга без
значительного изменения в семантике. Слабая метка объекта может
использоваться только для слабого сравнения.
Метка объекта ДОЛЖНА быть уникальна среди всех версий всех
объектов, связанных с конкретным ресурсом. Данное значение метки
объекта может использоваться для объектов, полученных запросами
различных URI без предположения эквивалентности этих объектов.
3.12 Еденицы измерения диапазонов (Range Units).
HTTP/1.1 позволяет клиенту запрашивать только часть объекта.
HTTP/1.1 использует еденицы измерения диапазонов в полях заголовка
Range (раздел 14.36) и Content-Range (раздел 14.17). Объект может
быть разбит на части соответственно различным структурным модулям.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
Единственая еденица измерения диапазонов, определенная в HTTP/1.1
- это "bytes". Реализации HTTP/1.1 могут игнорировать диапазоны,
определенные с использованием других едениц измерения. HTTP/1.1
был разработан, чтобы допускать реализации приложений, которые не
зависят от знания диапазонов.
4 HTTP сообщение (HTTP Message).
4.1 Типы сообщений.
HTTP сообщения делятся на запросы клиента серверу и ответы сервера
клиенту.
HTTP-message = Request | Response ; сообщения HTTP/1.1
Сообщения запроса (раздел 5) и ответа (раздел 6) используют
обобщенный формат сообщения RFC 822 [9] для пересылки объектов
(полезной нагрузки сообщения). Оба типа сообщений выглядят
следующим образом: сначала идет начальная строка (start-line),
затем один или несколько полей заголовка (называемых также просто
"заголовки"), затем пустая строка (то есть строка, равная CRLF),
указывающая конец полей заголовка, а затем, возможно, тело
сообщения.
В интересах ошибкоустойчивости, серверам СЛЕДУЕТ игнорировать
все пустые строки, полученные перед строкой запроса
(Request-Line). Другими словами, если сервер читает поток
протокола и в самом начале сообщения получает CRLF, то ему следует
этот CRLF игнорировать.
Обратите внимание: некоторые ошибочные реализации HTTP/1.0
клиентов генерируют дополнительные CRLF после запроса POST.
Стоит вновь повторить, что это явно запрещено нормальной записью
Бекуса-Наура. HTTP/1.1 клиент не должен добавлять дополнительные
CRLF перед запросом и после него.
4.2 Заголовки сообщений.
Поля заголовков HTTP, которые включают поля общих заголовков
(general-header) (раздел 4.5), заголовков запроса (request-header)
(раздел 5.3), заголовков ответа (response-header) (раздел 6.2), и
заголовков объекта (entity-header) (раздел 7.1), имеют такой же
обобщенный формат, что описан в разделе 3.1 RFC 822 [9]. Каждое
поле заголовка состоит из имени, двоеточия (":") и значения поля.
Имена полей не чувствительны к регистру. Значению поля может
предшествовать любое число LWS, хотя предпочтителен одиночный SP.
Поля заголовка могут занимать несколько строк. При этом каждая
следующая строка начинается по крайней мере одним SP или HT.
Приложениям СЛЕДУЕТ придерживаться "общей формы" ("common form")
при генерации HTTP конструкций, так как могут существовать
реализации, которые не в состоянии принимать что-либо кроме общих
форм.
field-content = <октеты, составляющие значение поля и
состоящие или из *TEXT или из комбинаций
лексем, tspecials, и quoted-string>
Порядок, в котором получены поля заголовка с различными именами
не имеет значения. Однако "хорошая практика" заключается в том,
что сначала посылаются поля общих заголовков, затем поля
заголовков запроса или заголовков ответа, и, наконец, поля
заголовков объекта.
Несколько полей заголовка с одиннаковыми именами могут
присутствовать в сообщении тогда, и только тогда, когда все
значения полей, входящих в заголовок, определяют разделенный
запятыми список [то есть #(value)]. ДОЛЖНО быть возможно
объединить несколько таких полей заголовка в одну пару "имя поля:
значение поля" (не измененяя этим семантику сообщения) присоединяя
каждое последующее значение поля к первому через запятые. Порядок,
в котором получены поля с одинаковыми именами, имеет значение
для интерпретации объединенного значения поля, и, следовательно,
прокси-сервер НЕ ДОЛЖЕН изменять порядок значений этого поля при
пересылке.
4.3 Тело cообщения.
Тело HTTP сообщения (message-body), если оно присутствует,
используется для передачи тела объекта, связанного с запросом или
ответом. Тело сообщения (message-body) отличается от тела объекта
(entity-body) только в том случае, когда применяется кодирование
передачи, что указывается полем заголовка Transfer-Encoding
(раздел 14.40).
message-body = entity-body
| <entity-body закодированно согласно
Transfer-Encoding>
Поле Transfer-Encoding ДОЛЖНО использоваться для указания любого
кодирования передачи, примененного приложением в целях
гарантирования безопасной и правильной передачи сообщения. Поле
Transfer-Encoding - это свойство сообщения, а не объекта, и, таким
образом, может быть добавлено или удалено любым приложением в
цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении,
отличны для запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к
заголовкам запроса поля заголовка Content-Length или
Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть
добавлено в запрос только когда метод запроса допускает тело
объекта (entity-body) (раздел 5.1.1).
Включается или не включается тело сообщения (message-body) в
сообщение ответа зависит как от метода запроса, так и от кода
состояния ответа (раздел 6.1.1). Все ответы на запрос с методом
HEAD НЕ ДОЛЖНЫ включать тело сообщения (message-body), даже если
присутствуют поля заголовка объекта (entity-header), заставляющие
поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx
(Информационные), 204 (Нет содержимого, No Content), и 304 (Не
модифицирован, Not Modified) НЕ ДОЛЖНЫ содержать тела сообщения
(message-body). Все другие ответы содержат тело сообщения, даже
если оно имеет нулевую длину.
4.4 Длина сообщения.
Когда тело сообщения (message-body) присутствует в сообщении,
длина этого тела определяется одним из следующих методов (в
порядке старшинства):
1. Любое сообщение ответа, которое НЕ ДОЛЖНО включать тело
сообщения (message-body) (например ответы с кодами состояния
1xx, 204, 304 и все ответы на запрос HEAD) всегда завершается
пустой строкой после полей заголовка, независимо от полей
заголовка объекта (entity-header fields), представленных в
сообщении.
2. Если поле заголовка Transfer-Encoding (раздел 14.40)
присутствует и указывает на применение кодирования передачи
"chunked", то длина определяется кодированием по кускам
(chunked encoding) (раздел 3.6).
3. Если поле заголовка Content-Length (раздел 14.14) присутствует,
то его значение представляет длину тела сообщения
(message-body) в байтах.
4. Если сообщение использует медиа тип "multipart/byteranges",
который саморазграничен, то он и определяет длину. Этот медиа
тип НЕ ДОЛЖЕН использоваться, если отправитель не знает, что
получатель может его обработать; присутствие в запросе
заголовка Range с несколькими спецификаторами диапазонов байтов
(byte-range) подразумевает, что клиент может анализировать
multipart/byteranges ответы.
5. Длина определяется закрытием соединения сервером. (Закрытие
соединения не может использоваться для указания конца тела
запроса, так как в этом случае у сервера не остается никакой
возможности послать обратно ответ).
Для совместимости с HTTP/1.0 приложениями HTTP/1.1 запросы,
содержащие тело сообщения (message-body) ДОЛЖНЫ включать
допустимое поле заголовка Content-Length, если не известно, что
сервер является HTTP/1.1 совместимым. Если запрос содержит тело
сообщения (message-body), и Content-Length не указано, серверу
СЛЕДУЕТ послать ответ с кодом состояния 400 (Испорченный Запрос,
Bad Request), если он не может определить длину сообщения, или
с кодом состояния 411 (Требуется длина, Length Required), если он
настаивает на получении Content-Length.
Все HTTP/1.1 приложения, которые получают объекты, ДОЛЖНЫ понимать
кодирование передачи типа "chunked" (раздел 3.6), таким образом
разрешается использование данного механизма для таких сообщений,
длина которых не может быть определена заранее.
Сообщения НЕ ДОЛЖНЫ одновременно включать и поле заголовка
Content-Length и применять кодирование передачи типа "chunked".
Если поступило сообщение с полем Content-Length и закодированное
с применением кодирования передачи "chunked", то поле
Content-Length ДОЛЖНО игнорироваться.
Если поле Content-Length присутствует в сообщении, которое
допускает наличие тела сообщения (message-body), то значение поля
ДОЛЖНО точно соответствовать числу октетов в теле сообщения.
HTTP/1.1 агенты пользователя ДОЛЖНЫ информировать пользователя в
случае получения и обнаружения недопустимой длины.
4.5 Общие поля заголовка.
Имеется несколько полей заголовка, которые применяются как для
сообщений запросов, так и для сообщений ответов, но которые не
применяются к передаваемому объекту. Эти поля заголовка
применяются только к передаваемому сообщению.
general-header = Cache-Control ; Раздел 14.9
| Connection ; Раздел 14.10
| Date ; Раздел 14.19
| Pragma ; Раздел 14.32
| Transfer-Encoding ; Раздел 14.40
| Upgrade ; Раздел 14.41
| Via ; Раздел 14.44
Имена общих полей заголовка (general-header fields) могут быть
надежно расширены только в сочетании с изменением версии протокола.
Однако, новые или экспериментальные поля заголовка могут получить
семантику общих полей заголовка (general-header fields), если все
стороны соединения распознают их как общие поля заголовка.
Нераспознанные поля заголовка обрабатываются как поля заголовка
объекта (entity-header).
5 Запрос (Request).
Сообщение запроса от клиента к серверу содержит в первой строке:
метод, который нужно применить к ресурсу, идентификатор ресурса
и используемую версию протокола.
Request = Request-Line ; Раздел 5.1
*( general-header ; Раздел 4.5
| request-header ; Раздел 5.3
| entity-header ) ; Раздел 7.1
CRLF
[ message-body ] ; Раздел 7.2
5.1 Строка запроса (Request-Line).
Строка запроса (Request-Line) начинается с лексемы метода, затем
следует запрашиваемый URI (Request-URI), версия протокола и CRLF.
Эти элементы разделяются SP. В строке запроса (Request-Line) не
допустимы CR и LF, исключение составляет конечная
последовательность CRLF.
Лексема метода указывает метод, который нужно применить к ресурсу,
идентифицированному запрашиваемым URI (Request-URI). Метод
чувствителен к регистру.
Method = "OPTIONS" ; Раздел 9.2
| "GET" ; Раздел 9.3
| "HEAD" ; Раздел 9.4
| "POST" ; Раздел 9.5
| "PUT" ; Раздел 9.6
| "DELETE" ; Раздел 9.7
| "TRACE" ; Раздел 9.8
| extension-method
extension-method = token
Список методов, применимых к ресурсу, может быть указан в поле
заголовка Allow (раздел 14.7). Возврашаемый код состояния ответа
всегда сообщает клиенту, допустим ли метод для ресурса в настоящее
время, так как набор допустимых методов может изменяться
динамически. Серверам СЛЕДУЕТ возвратить код состояния 405 (Метод
не дозволен, Method Not Allowed), если метод известен серверу, но
не применим для запрошенного ресурса, и 501 (Не реализовано, Not
Implemented), если метод не распознан или не реализован сервером.
Список методов, известных серверу, может быть указан в поле
заголовка ответа Public (раздел 14.35).
Методы GET и HEAD ДОЛЖНЫ поддерживаться всеми универсальными
(general-purpose) серверами. Остальные методы опциональны; однако,
если вышеупомянутые методы реализованы, то они ДОЛЖНЫ иметь
семантику, описанную в разделе 9.
5.1.2 Запрашиваемый URI (Request-URI).
Запрашиваемый URI (Request-URI) - это Единообразный Идентификатор
Ресурса (URL, раздел 3.2), который идентифицирует ресурс запроса.
Request-URI = "*" | absoluteURI | abs_path
Три опции для запрашиваемого URI (Request-URI) зависят от
характера запроса. Звездочка "*" означает, что запрос обращается
не к специфическому ресурсу, а к серверу непосредственно, и
допускается только в том случае, когда используемый метод не
обязательно обращается к ресурсу.
В качестве примера:
OPTIONS * HTTP/1.1
absoluteURI необходим, когда запрос производится через
прокси-сервер. Прокси-сервер перенаправляет запрос на сервер или
обслуживает его, пользуясь кэшем, и возвращает ответ. Обратите
внимание, что прокси-сервер МОЖЕТ переслать запрос другому
прокси-серверу или непосредственно серверу, определенному
absoluteURI. Чтобы избежать зацикливания запроса прокси-сервер
ДОЛЖЕН быть способен распознавать все имена сервера, включая любые
псевдонимы, локальные разновидности, и числовые IP адреса.
Request-Line может быть, например, таким:
Чтобы обеспечить переход к absoluteURI во всех запросах в будущих
версиях HTTP, все HTTP/1.1 серверы ДОЛЖНЫ принимать absoluteURI
в запросах, хотя HTTP/1.1 клиенты будут генерировать их только в
запросах к прокси-серверам.
Наиболее общая форма Request-URI - та, которая используется для
идентификации ресурса на первоначальном сервере или шлюзе. В этом
случае абсолютный путь URI (смотрите раздел 3.2.1, abs_path)
ДОЛЖЕН быть передан как Request-URI, а сетевое расположение URI
(net_loc) ДОЛЖНО быть передано в поле заголовка Host. Для
последнего примера клиент, желающий получить ресурс
непосредственно с первоначального сервера должен создать TCP
соединение на 80 порт хоста "www.w3.org" и послать строки:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
и далее остаток запроса. Обратите внимание, что абсолютный путь не
может быть пустым; если оригинальный URI пуст, то он ДОЛЖЕН
запрашиваться как "/" (корневой каталог сервера).
Если прокси-сервер получает запрос без пути в Request-URI, и метод
запроса допускает форму запроса "*", то последний прокси-сервер в
цепочке запросов ДОЛЖЕН передать запрос, в котором Request-URI
равен "*". Например запрос
после соединения с портом 8001 хоста "www.ics.uci.edu".
Request-URI передается в формате, определенном в разделе 3.2.1.
Первоначальный сервер ДОЛЖЕН декодировать Request-URI, чтобы
правильно интерпретировать запрос. Серверам СЛЕДУЕТ отвечать на
недопустимые Request-URI соответствующим кодом состояния.
В запросах, которые передаются далее, прокси-сервера никогда НЕ
ДОЛЖНЫ перезаписывать часть "abs_path" запрашиваемого URI
(Request-URI), за исключением случая, отмеченного выше, когда
пустой abs_path заменяется на "*", независимо от внутренней
реализации прокси-сервера.
Обратите внимание: правило "ничто не перезаписывать"
предохраняет прокси-сервера от изменения значения запроса,
в котором первоначальный сервер неправильно использует не
зарезервированные символы URL для своих целей. Реализаторам
следует знать, что некоторые до-HTTP/1.1 прокси-сервера, как
известно, перезаписывали Request-URI.
5.2 Ресурс, идентифицируемый запросом.
Первоначальные HTTP/1.1 сервера ДОЛЖНЫ учитывать, что точный
ресурс, идентифицированный интернет-запросом определяется
исследованием как Request-URI, так и поля заголовка Host.
Первоначальный сервер, который не позволяет ресурсам отличаться по
запрошенному хосту (host), МОЖЕТ игнорировать значение поля
заголовка Host. (Но смотрите раздел 19.5.1 для других требований
по поддержке Host в HTTP/1.1).
Первоначальный сервер, который различает ресурсы, основанные на
запрошенном хосте (иногда называемые виртуальными хостами или
vanity hostnames) ДОЛЖЕН использовать следующие правила для
определения запрошенного в HTTP/1.1 запросе ресурса:
1. Если Request-URI - это absoluteURI, то хост - это часть
Request-URI. Любое значение поля заголовка Host в запросе
ДОЛЖНО игнорироваться.
2. Если Request-URI - не absoluteURI, а запрос содержит поле
заголовка Host, то хост определяется значением поля
заголовка Host.
3. Если хоста, определенного правилами 1 или 2 не существует на
сервере, код состояния ответа ДОЛЖЕН быть 400 (Испорченный
Запрос, Bad Request).
Получатели HTTP/1.0 запроса, в котором недостает поля заголовка
Host, МОГУТ пытаться использовать эвристику (например, исследовать
путь в URI на предмет уникальности на каком-либо из хостов) чтобы
определить какой точно ресурс запрашивается.
5.3 Поля заголовка запроса.
Поля заголовка запроса позволяют клиенту передавать серверу
дополнительную информацию о запросе и о самом клиенте. Эти поля
действуют как модификаторы запроса с семантикой, эквивалентной
параметрам вызова методов в языках программирования.
request-header = Accept ; Раздел 14.1
| Accept-Charset ; Раздел 14.2
| Accept-Encoding ; Раздел 14.3
| Accept-Language ; Раздел 14.4
| Authorization ; Раздел 14.8
| From ; Раздел 14.22
| Host ; Раздел 14.23
| If-Modified-Since ; Раздел 14.24
| If-Match ; Раздел 14.25
| If-None-Match ; Раздел 14.26
| If-Range ; Раздел 14.27
| If-Unmodified-Since ; Раздел 14.28
| Max-Forwards ; Раздел 14.31
| Proxy-Authorization ; Раздел 14.34
| Range ; Раздел 14.36
| Referer ; Раздел 14.37
| User-Agent ; Раздел 14.42
Имена полей заголовка запроса (Request-header) могут быть надежно
расширены только в сочетании с изменением версии протокола.
Однако, новые или экспериментальные поля заголовка могут получить
семантику полей заголовка запроса (Request-header), если все
стороны соединения распознают их как поля заголовка запроса
(Request-header). Нераспознанные поля заголовка обрабатываются
как поля заголовка объекта (entity-header).
6 Ответ (Response).
После получения и интерпретации сообщения запроса, сервер отвечает
сообщением HTTP ответа.
Response = Status-Line ; Раздел 6.1
*( general-header ; Раздел 4.5
| response-header ; Раздел 6.2
| entity-header ) ; Раздел 7.1
CRLF
[ message-body ] ; Раздел 7.2
6.1 Строка состояния (Status-Line).
Первая строка ответа - это строка состояния (Status-Line). Она
состоит из версии протокола (HTTP-Version), числового кода
состояния (Status-Code) и поясняющей фразы (Reason-Phrase),
разделенных символами SP. CR и LF не допустимы в
Status-Line, за исключением конечной последовательности CRLF.
Элемент код состояния (Status-Code) - это целочисленный
трехразрядный код результата понимания и удовлетворения запроса.
Эти коды полностью определены в разделе 10. Поясняющая фраза
(Reason-Phrase) предназначена для короткого текстового описания
кода состояния. Код состояния (Status-Code) предназначен для
использования автоматами, а поясняющая фраза предназначена для
живых пользователей. От клиента не требуется исследовать или
отображать поясняющую фразу (Reason-Phrase).
Первая цифра кода состояния определяет класс ответа. Последние две
цифры не имеют определенной роли в классификации. Имеется 5
значений первой цифры:
o 1xx: Информационные коды - запрос получен, продолжается
обработка.
o 2xx: Успешные коды - действие было успешно получено, понято
и обработано.
o 3xx: Коды перенаправления - для выполнения запроса должны
быть предприняты дальнейшие действия.
o 4xx: Коды ошибок клиента - запрос имеет плохой синтаксис
или не может быть выполнен.
o 5xx: Коды ошибок сервера - сервер не в состоянии выполнить
допустимый запрос.
Конкретные значения числовых кодов состояния, определенных в
HTTP/1.1, и примерный набор соответствующих поясняющих фраз
(Reason-Phrase) приводятся ниже. Поясняющие фразы (Reason-Phrase),
перечисленные здесь являются рекомендуемыми, но могут быть
заменены на эквивалентные без воздействия на протокол.
Status-Code = "100" ; Продолжать, Continue
| "101" ; Переключение протоколов,
; Switching Protocols
| "200" ; OK
| "201" ; Создан, Created
| "202" ; Принято, Accepted
| "203" ; Не авторская информация,
; Non-Authoritative Information
| "204" ; Нет содержимого, No Content
| "205" ; Сбросить содержимое, Reset
; Content
| "206" ; Частичное содержимое, Partial
; Content
| "300" ; Множественный выбор, Multiple
; Choices
| "301" ; Постоянно перенесен, Moved
; Permanently
| "302" ; Временно перемещен, Moved
; Temporarily
| "303" ; Смотреть другой, See Other
| "304" ; Не модифицирован, Not Modified
| "305" ; Используйте прокси-сервер, Use
; Proxy
| "400" ; Испорченный Запрос, Bad Request
| "401" ; Несанкционированно, Unauthorized
| "402" ; Требуется оплата, Payment
; Required
| "403" ; Запрещено, Forbidden
| "404" ; Не найден, Not Found
| "405" ; Метод не дозволен, Method Not
; Allowed
| "406" ; Не приемлем, Not Acceptable
| "407" ; Требуется установление
; подлинности через прокси-сервер,
; Proxy Authentication Required
| "408" ; Истекло время ожидания запроса,
; Request Timeout
| "409" ; Конфликт, Conflict
| "410" ; Удален, Gone
| "411" ; Требуется длина, Length Required
| "412" ; Предусловие неверно,
; Precondition Failed
| "413" ; Объект запроса слишком большой,
; Request Entity Too Large
| "414" ; URI запроса слишком длинный,
; Request-URI Too Long
| "415" ; Неподдерживаемый медиа тип,
; Unsupported Media Type
| "500" ; Внутренняя ошибка сервера,
; Internal Server Error
| "501" ; Не реализовано, Not Implemented
| "502" ; Ошибка шлюза, Bad Gateway
| "503" ; Сервис недоступен, Service
; Unavailable
| "504" ; Истекло время ожидания от шлюза,
; Gateway Timeout
| "505" ; Не поддерживаемая версия HTTP,
; HTTP Version Not Supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT не включающий CR, LF>
Коды состояния HTTP расширяемы. HTTP приложениям не требуется
понимать значение всех зарегистрированных кодов состояния, хотя
такое понимание очень желательно. Однако, приложения ДОЛЖНЫ
понимать класс любого кода состояния, который обозначается первой
цифрой, и обрабатывать любой нераспознанный ответ как
эквивалентный коду состояния x00 этого класса, за исключением тех
случаев, когда нераспознанный ответ НЕ ДОЛЖЕН кэшироваться.
Например, если клиентом получен и не был распознан код
состояния 431, то он может безопасно считать, что в запросе что-то
было неправильно и обрабатывать ответ, как если бы был получен код
состояния 400. В таких случаях агентам пользователя СЛЕДУЕТ
представить пользователю объект, возвращенный в ответе, так как
этот объект, вероятно, включает читабельную для человека
информацию, которая поясняет необычное состояние.
6.2 Поля заголовка ответа.
Поля заголовка ответа (response-header fields) позволяют серверу
передавать дополнительную информацию, касающуюся ответа, которая
не может быть помещена в строку состояния Status-Line. Эти поля
заголовка дают информацию о сервере и о дальнейшем доступе к
ресурсу, указанному этим Request-URI.
response-header = Age ; Раздел 14.6
| Location ; Раздел 14.30
| Proxy-Authenticate ; Раздел 14.33
| Public ; Раздел 14.35
| Retry-After ; Раздел 14.38
| Server ; Раздел 14.39
| Vary ; Раздел 14.43
| Warning ; Раздел 14.45
| WWW-Authenticate ; Раздел 14.46
Имена полей заголовка ответа (Response-header) могут быть надежно
расширены только в сочетании с изменением версии протокола.
Однако, новые или экспериментальные поля заголовка могут получить
семантику полей заголовка ответа (Response-header), если все
стороны соединения распознают их как поля заголовка ответа
(Response-header). Нераспознанные поля заголовка обрабатываются
как поля заголовка объекта (entity-header).
Множество имен полей заголовка ответа (Response-header) может быть
надежно расширено только в комбинации с изменением версии протокола.
Однако, новые или экспериментальные поля заголовка с семантикой
полей заголовка ответа МОГУТ быть добавлены если все участники
соединения распознают их как поля заголовка ответа. Нераспознанные
поля заголовка обрабатываются как поля заголовка объекта.
7 Объект (Entity).
Сообщения запросов и ответов МОГУТ передать объект, если иное не
установлено методом запроса или кодом состояния ответа. Объект
состоит из полей заголовка объекта (entity-header) и тела объекта
(entity-body), хотя некоторые ответы могут включать только
заголовки объекта (entity-headers).
Этот раздел относится как к отправителю, так и к получателю, то
есть к клиенту или серверу, в зависимости от того, кто посылает,
а кто получает объект.
7.1 Поля заголовка объекта.
Поля заголовка объекта (Entity-header fields) определяют
опциональную метаинформацию о теле объекта или, если тело не
присутствует, относительно ресурса, идентифицированного запросом.
entity-header = Allow ; Раздел 14.7
| Content-Base ; Раздел 14.11
| Content-Encoding ; Раздел 14.12
| Content-Language ; Раздел 14.13
| Content-Length ; Раздел 14.14
| Content-Location ; Раздел 14.15
| Content-MD5 ; Раздел 14.16
| Content-Range ; Раздел 14.17
| Content-Type ; Раздел 14.18
| ETag ; Раздел 14.20
| Expires ; Раздел 14.21
| Last-Modified ; Раздел 14.29
| extension-header
extension-header = message-header
Механизм расширения полей заголовка позволяет вводить
дополнительные поля заголовка объекта (entity-header fields) не
изменяя протокол, но эти поля не могут считаться распознаваемыми
получателем. Нераспознанные поля заголовка получателю СЛЕДУЕТ
игнорировать, а прокси-серверу пересылать без изменений.
7.2 Тело объекта.
Тело объекта (если оно присутствует) посылается с HTTP запросом
или ответом и имеет формат и кодирование, определяемое полями
заголовка объекта (entity-header fields).
entity-body = *OCTET
Тело объекта (entity-body) представлено в сообщении только тогда,
когда присутствует тело сообщения (message-body), как описано в
разделе 4.3. Тело объекта (entity-body) получается из тела
сообщения (message-body), декодированием кодирования передачи,
указанного в поле Transfer-Encoding, и которое может быть
применено для гарантирования безопасной и правильной передачи
сообщения.
7.2.1 Тип (Type).
Когда тело объекта (entity-body) включено в сообщение, тип данных
этого тела определяется полями заголовка Content-Type и
Content-Encoding. Они определяют двухуровневую упорядоченную
модель кодирования:
entity-body := Content-Encoding( Content-Type( data ) )
Тип содержимого (Content-Type) определяет медиа тип основных
данных. Кодирование содержимого (Content-Encoding) может
использоваться для указания любого дополнительного кодирования
содержимого, примененного к данным (обычно с целью сжатия данных).
Кодирование содержимого (Content-Encoding) является свойством
запрошенного ресурса. По умолчанию никакого кодирования не задано.
В любое HTTP/1.1 сообщение, содержащее тело объекта (entity-body)
СЛЕДУЕТ включать поле заголовка Content-Type, определяющее медиа
тип этого тела. В том и только в том случае, когда медиа тип не
представлен полем Content-Type, получатель МОЖЕТ попытаться
предположить медиа тип, проверяя содержимое и/или расширение
(расширения) в имени URL, используемого для идентификации ресурса.
Если медиа тип остался нераспознан, получателю СЛЕДУЕТ
обрабатывать его как тип "application/octet-stream".
7.2.2 Длина (Length).
Длина тела объекта (entity-body) - это длина тела сообщения
(message-body), полученного после декодирования всех кодирований
передачи. Раздел 4.4 определяет как вычисляется длина тела
сообщения (message-body).
8 Соединения (Connections).
8.1 Постоянные соединения (Persistent Connections).
8.1.1 Цель.
До постоянных соединений для запроса каждого URL устанавливалось
отдельное TCP соединение, что увеличивало нагрузку на HTTP сервера
и вызывало загрузку Интернета. Использование встроенных
изображений и других связанных данных часто требует от клиента
делать несколько запросов к одному серверу за короткий промежуток
времени. Исследования проблем эффективности такого решения
доступны в [30][27]; анализ и результаты реализации прототипа
находятся в [26].
Постоянные HTTP соединения имеют ряд преимуществ:
o Открытие и закрытие меньшего количества TCP соединений
экономит время центрального процессора и память, используемую
для управляющих блоков протокола TCP.
o HTTP запросы и ответы может быть конвейеризованы в
соединении. Конвейерная обработка позволяет клиенту делать
множество запросов не ожидая ответа на каждый, следовательно,
одиночное TCP соединение, использование которого намного
более эффективно, теряет меньше времени.
o Загрузка сети уменьшается с уменьшением числа пакетов,
вызванных открытием TCP соединений, и, следовательно, дает
протоколу TCP достаточное время для определения состояния
загрузки сети.
o HTTP может развиваться более элегантно; так как ошибки могут
сообщаться без закрытия TCP соединения в качестве штрафа.
Клиенты, использующие будущие версии HTTP могли бы
оптимистично пробовать новые возможности, но при связи со
старым сервером, повторять запрос, используя старую
семантику после сообщения об ошибке.
HTTP реализациям СЛЕДУЕТ реализовывать постоянные соединения.
8.1.2 Общее описание.
Значительное отличие HTTP/1.1 от более ранних версий HTTP состоит
в том, что постоянные соединения являются заданным по умолчанию
поведением любого HTTP соединения. То есть если не обозначено
иного, клиент может считать, что сервер поддержит постоянное
соединение.
Постоянные соединения обеспечивают механизм, согласно которому
клиент и сервер могут сообщить о разрыве TCP соединения. Это
сигнализируется при помощи использования поля заголовка
Connection. При получении сообщения о разрыве соединения клиент
НЕ ДОЛЖЕН посылать больше запросов по этому соединению.
8.1.2.1 Обсуждение (Negotiation).
HTTP/1.1 сервер МОЖЕТ считать, что HTTP/1.1 клиент не предполагает
поддерживать постоянное соединение, если посланный в запросе
заголовок Connection содержит лексему соединения
(connection-token) "close". Если сервер решает закрыть соединение
немедленно после посылки ответа, то ему СЛЕДУЕТ послать заголовок
Connection, который содержит лексему соединения (connection-token)
"close".
HTTP/1.1 клиент МОЖЕТ ожидать, что соединение останется открытым,
но должен решить оставлять ли его открытым на основании того,
содержит ли ответ сервера заголовок Connection с лексемой
соединения "close". В случае, если клиент не хочет поддерживать
соединение для последующих запросов, ему СЛЕДУЕТ послать заголовок
Connection, содержащий лексему соединения "close".
Если клиент или сервер посылает лексему закрытия соединения
"close" в заголовке Connection, то запрос становится последним
в соединении.
Клиентам и серверам НЕ СЛЕДУЕТ считать, что постоянное соединение
поддерживается HTTP версиями, меньшими чем 1.1, если это не
указано явно. Смотрите раздел 19.7.1 с более подробной информацией
о обратной совместимости с HTTP/1.0 клиентами.
Чтобы соединение оставалось постоянным, все сообщения,
передаваемые по нему должны иметь самоопределенную (self-defined)
длину сообщения (то есть, не определяемую закрытием соединения),
как описано в разделе 4.4.
8.1.2.2 Конвейерная обработка (Pipelining).
Клиент, который поддерживает постоянные соединения МОЖЕТ
"произвести конвейерную обработку" запросов (то есть, посылать
несколько запросов не ожидая ответа на каждый). Сервер ДОЛЖЕН
послать ответы на эти запросы в том же самом порядке, в каком
были получены запросы.
Клиенты, которые поддерживают постоянные соединения и производят
конвейерную обработку немедленно после установления соединения,
ДОЛЖНЫ быть готовы повторить соединение, если первая попытка
конвейерной обработки дала сбой. Если клиент делает такой повтор,
он НЕ ДОЛЖЕН производить конвейерную обработку прежде, чем узнает,
что соединение постоянное. Клиенты ДОЛЖНЫ также быть готовы снова
послать запросы, если сервер закрывает соединение перед посылкой
всех соответствующих ответов.
8.1.3 Прокси-сервера (Proxy Servers).
Очень важно, чтобы прокси-сервера правильно выполняли свойства
полей заголовка Connection, как определено в 14.2.1.
Прокси-сервер ДОЛЖЕН сообщать о постоянных соединениях отдельно
своим клиентам и отдельно первоначальным серверам (или другим
прокси-серверам), которые с ним соединены. Каждое постоянное
соединение применяется только к одной транспортной связи.
Прокси-сервер НЕ ДОЛЖЕН устанавливать постоянное соединение с
HTTP/1.0 клиентом.
Сервера обычно имеют некоторое значение времени ожидания, после
которого они не поддерживают неактивное соединение. Прокси-сервера
могут делать это значение более высоким, так как, вероятно, клиент
сделает большее количество соединений через этот же сервер.
Использование постоянных соединений не вводит никаких ограничений
на продолжительность этого времени ожидания как для клиента, так
и для сервера.
Когда у клиента или сервера истекло время ожидания, ему СЛЕДУЕТ
произвести изящное закрытие транспортного соединения. Как
клиентам, так и серверам СЛЕДУЕТ постоянно наблюдать за другой
стороной на предмет закрытия соединения, и соответственно
отвечать. Если клиент или сервер не обнаруживает закрытия
соединения другой стороной сразу, то это вызывает не оправданную
трату ресурсов сети.
Клиент, сервер, или прокси-сервер МОГУТ закрыть транспортное
соединение в любое время. Например, клиент МОЖЕТ начать посылать
новый запрос в то время, когда сервер решает закрыть
"бездействующее" соединение. С точки зрения сервера, соединение
закрывается, в то время как оно было неактивно, но с точки зрения
клиента, запрос произошел.
Это означает, что клиенты, серверы, и прокси-серверы ДОЛЖНЫ быть
в состоянии обрабатывать асинхронные события закрытия.
Программному обеспечению клиента СЛЕДУЕТ вновь открыть
транспортное соединение и повторно передать прерванный запрос без
? взаимодействия с пользователем, поскольку метод запроса
idempotent (смотрите раздел 9.1.2); другие методы НЕ ДОЛЖНЫ быть
повторены автоматически, хотя агенты пользователя МОГУТ предложить
оператору выбор повторять запрос, или нет.
Однако это автоматическое повторение НЕ СЛЕДУЕТ производить, если
сбой происходит уже во втором запросе.
Серверам всегда СЛЕДУЕТ отвечать на по крайней мере на один запрос
в соединении, если это возможно. Серверам НЕ СЛЕДУЕТ разрывать
соединение в середине передачи ответа, если не предполагается
сетевой или клиентский отказ.
Клиентам, использующим постоянные соединения, СЛЕДУЕТ ограничить
число одновременных соединений, которые они устанавливают с данным
сервером. Однопользовательскому клиенту СЛЕДУЕТ устанавливать
максимум 2 соединения с любым сервером или прокси-сервером.
Прокси-серверу СЛЕДУЕТ ограничиться 2*N соединеними с другими
серверами или прокси-серверами, где N - число одновременно
активных пользователей. Эти руководящие принципы предназначены
для уменьшения времени HTTP ответа и избежания чрезмерной загрузки
Интернета или других сетей.
8.2 Требования к передаче сообщений.
Общие требования:
o HTTP/1.1 серверам СЛЕДУЕТ поддерживать постоянные соединения и
использовать механизмы управления потоком данных TCP в целях
уменьшения временных перегрузок, вместо закрытия соединений,
которые, как ожидается, могут быть повторно использованы
клиентами. Последняя методика может усиливать сетевую загрузку.
o HTTP/1.1 (или более поздним) клиентам, посылающим тело
сообщения (message-body) СЛЕДУЕТ контролировать сетевое
соединение на предмет ошибок во время передачи запроса. Если
клиент обнаруживает ошибку, ему СЛЕДУЕТ немедленно прекратить
передачу тела сообщения. Если тело посылается с использованием
кодирования "по кускам" ("chunked", раздел 3.6), то кусок
нулевой длины, и пустой завершитель МОГУТ использоваться для
индикации преждевременного конца сообщения. Если телу
предшествовал заголовок Content-Length, клиент ДОЛЖЕН закрыть
соединение.
o HTTP/1.1 (или более поздний) клиент ДОЛЖЕН быть готов принять
ответ с кодом состояния 100 (Продолжать, Continue),
предшествующий основному ответу.
o HTTP/1.1 (или более поздний) сервер, который получает запрос от
HTTP/1.0 (или более раннего) клиента НЕ ДОЛЖЕН передать ответ
с кодом состояния 100 (Продолжать, Continue); ему СЛЕДУЕТ либо
ожидать пока запрос будет выполнен обычным образом (то есть без
использования прерванного запроса), либо преждевременно закрыть
соединение.
После получения метода, подчиненного этим требованиям, от HTTP/1.1
(или более позднего) клиента, HTTP/1.1 (или более поздний) сервер
ДОЛЖЕН либо ответить кодом состояния 100 (Продолжать, Continue) и
продолжать чтение входного потока, либо ответить ошибочным кодом
состояния. Если сервер ответил ошибочным кодом состояния, то он
МОЖЕТ либо закрыть транспортное соединение (TCP), либо продолжать
читать и отбрасывать оставшуюся часть запроса. Он НЕ ДОЛЖЕН
выполнять запрошенный метод, если возвратил код состояния ошибки.
Клиентам СЛЕДУЕТ помнить номер версии HTTP, используемой сервером
по крайней мере в последний раз; если HTTP/1.1 клиент встречал
HTTP/1.1 или более поздний ответ от сервера, и видит закрытие
соединения перед получением какого-либо кода состояния от сервера,
клиенту СЛЕДУЕТ повторить запрос без взаимодействия с
? пользователем, поскольку метод запроса idempotent (смотрите
раздел 9.1.2); другие методы НЕ ДОЛЖНЫ быть повторены
автоматически, хотя агенты пользователя МОГУТ предложить оператору
выбор повторять запрос, или нет. Если клиент повторяет запрос,
то он
o ДОЛЖЕН сначала послать поля заголовка запроса, а затем
o ДОЛЖЕН ожидать ответа сервера с кодом 100 (Продолжать,
Continue), а затем продолжать, или с кодом состояния ошибки.
Если HTTP/1.1 клиент не встречал ответа сервера версии HTTP/1.1
или более поздней, то ему следует считать, что сервер реализует
HTTP/1.0 или более старый протокол и не использовать ответы с
кодом состояния 100 (Продолжать, Continue). Если в такой ситуации
клиент видит закрытие соединения перед получением какого-либо
ответа с кодом состояния от сервера, то ему СЛЕДУЕТ повторить
запрос. Если клиент повторяет запрос к этому HTTP/1.0 серверу, то
? он должен использовать следующий "binary exponential backoff"
алгоритм, чтобы быть уверенным в получении надежного ответа:
1. Инициализировать новое соединение с сервером.
2. Передать заголовки запроса (request-headers).
3. Инициализировать переменную R примерным временем передачи
информации на сервер и обратно (например на основании времени
установления соединения), или постоянным значение в 5 секунд,
если время передачи не доступно.
4. Вычислить T = R * (2**N), где N - число предыдущих повторов
этого запроса.
5. Либо дождаться от сервера ответа с кодом ошибки, либо просто
выждать T секунд (смотря что произойдет раньше).
6. Если ответа с кодом ошибки не получено, после T секунд передать
тело запроса.
7. Если клиент обнаруживает, что соединение было закрыто
преждевременно, то ему нужно повторять начиная с шага 1, пока
запрос не будет принят, либо пока не будет получен ошибочный
ответ, либо пока у пользователя не кончится терпение и он не
завершит процесс повторения.
Независимо от того, какая версия HTTP реализована сервером, если
клиент получает ошибочный код состояния, то он
o НЕ ДОЛЖЕН продолжать и
o ДОЛЖЕН закрыть соединение, если он не завершил посылку
сообщения.
HTTP/1.1 (или более позднему) клиенту, который обнаруживает
закрытие соединения после получения ответа с кодом состояния 100
(Продолжать, Continue), но до получения ответа с другим кодом
состояния, СЛЕДУЕТ повторить запрос, но уже не ожидать ответа с
кодом состояния 100 (Продолжать, Continue) (но он МОЖЕТ сделать
так, если это упрощает реализацию).
9 Определения методов (Method Definitions).
Набор общих методов для HTTP/1.1 приводится ниже. Хотя этот набор
может быть расширен, нельзя считать, что дополнительные методы
имеют одиннаковую семантику, если они являются расширениями
разных клиентов и серверов.
Поле заголовка запроса Host (раздел 14.23) ДОЛЖНО сопровождать
все HTTP/1.1 запросы.
9.1 Безопасные и Idempotent методы.
9.1.1 Безопасные методы.
Программистам следует понимать, что программное обеспечение при
взаимодействии с Интернетом представляет пользователя, и программе
следует информировать пользователя о любых действиях, которые он
может произвести, но которые могут иметь непредсказуемое значение
для него или других лиц.
В частности было принято соглашение, что методы GET и HEAD никогда
не должны иметь иного значения, кроме загрузки. Эти методы следует
рассматривать как "безопасные". Это позволяет агентам пользователя
представлять другие методы, такие как POST, PUT и DELETE, таким
образом, чтобы пользователь был проинформирован о том, что он
запрашивает выполнение потенциально опасного действия.
Естественно, не возможно гарантировать, что сервер не генерирует
побочные эффекты в результате выполнения запроса GET; фактически,
некоторые динамические ресурсы содержат такую возможность. Важное
различие здесь в том, что не пользователь запрашивает побочные
эффекты, и, следовательно, пользователь не может нести
ответственность за них.
9.1.2 Idempotent методы.
Методы могут также обладать свойством "idempotence" в том смысле,
что побочные эффекты от N > 0 идентичных запросов такие же, как
от одиночного запроса (за исключение ошибок и проблем
устаревания). Методы GET, HEAD, PUT и DELETE обладают данным
свойством.
9.2 OPTIONS.
Метод OPTIONS представляет запрос информации об опциях соединения,
доступных в цепочке запросов/ответов, идентифицируемой
запрашиваемым URI (Request-URI). Этот метод позволяет клиенту
определять опции и/или требования, связанные с ресурсом, или
возможностями сервера, но не производя никаких действий над
ресурсом и не инициируя его загрузку.
Если ответ сервера - это не сообщение об ошибке, то ответ НЕ
ДОЛЖЕН содержать иной информации объекта, кроме той, которую можно
рассматривать как опции соединения (например Allow - можно
рассматривать как опцию соединения, а Content-Type - нет). Ответы
на этот метод не кэшируются.
Если запрашиваемый URI (Request-URI) - звездочка ("*"), то запрос
OPTIONS предназначен для обращения к серверу в целом. Если код
состояния в ответе - 200, то ответу СЛЕДУЕТ содержать любые поля
заголовка, которые указывают опциональные возможности, реализуемые
сервером (например, Public), включая любые расширения, не
определенные данной спецификацией, в дополнение к соответствующим
общим полям или полям заголовка ответа (response-header). Как
описано в разделе 5.1.2, запрос "OPTIONS *" может быть применен
через прокси-сервер с определением адресуемого сервера в
запрашиваемом URI (Request-URI) с пустым путем.
Если запрашиваемый URI (Request-URI) не звездочка ("*"), то запрос
OPTIONS применяется к опциям, которые доступны при соединении с
указанным ресурсом. Если код состояния ответа - 200, то ответу
СЛЕДУЕТ содержать любые поля заголовка, которые указывают
опциональные возможности, реализуемые сервером и применимые к
указанному ресурсу (например, Allow), включая любые расширения, не
определенные данной спецификацией, в дополнение к соответствующим
общим полям или полям заголовка ответа (response-header). Если
запрос OPTIONS передается через прокси-сервер, то последний
редактирует ответ, исключая те опции, которые не предусмотрены
возможности этого прокси-сервера.
9.3 GET.
Метод GET позволяет получать любую информацию (в форме объекта),
идентифицированную запрашиваемым URI (Request-URI). Если
запрашиваемый URI (Request-URI) обращается к процессу,
производящему данные, то в качестве объекта ответа должны быть
возвращены произведенные данные, а не исходный текст процесса,
если сам процесс не выводит исходный текст.
Различается "условный GET" ("conditional GET"), при котором
сообщение запроса включает поля заголовка If-Modified-Since,
If-Unmodified-Since, If-Match, If-None-Match, или If-Range.
Условный метод GET запрашивает передачу объекта, только если он
удовлетворяет условиям, описанным в условных полях заголовка.
Условный метод GET предназначен для уменьшения ненужной загрузки
сети, и позволяет обновлять кэшированные объекты без использования
нескольких запросов или пересылки данных, уже сохраненных
клиентом.
Различается также "частичный GET" ("partial GET"), при котором
сообщение запроса включает поле заголовка Range. Частичный GET
запрашивает передачу только части объекта, как описано в разделе
14.36. Частичный метод GET предназначен для уменьшения ненужной
загрузки сети, и позволяет собирать объекты из частей, без
передачи частей данных, уже сохраненных клиентом.
Ответ на запрос GET кэшируем тогда и только тогда, когда он
отвечает требованиям HTTP кэширования, описанным в разделе 13.
9.4 HEAD.
Метод HEAD идентичен GET, за исключением того, что сервер НЕ
ДОЛЖЕН возвращать в ответе тело сообщения (message-body).
Метаинформации, содержащейся в HTTP заголовках ответа на запрос
HEAD СЛЕДУЕТ быть идентичной информации, представляемой в ответ
на запрос GET. Этот метод может использоваться для получения
метаинформации об объекте запроса без непосредственной пересылки
тела объекта (entity-body). Этот метод часто используется для
тестирования гипертекстовых связей в целях проверки правильности,
достижимости, и времени модификации.
Ответ на запрос HEAD может быть кэшируемым в том смысле, что
информация, содержащаяся в ответе может использоваться для
модифицикации предварительно кэшированного объекта из этого
ресурса. Если новые значения поля указывают, что кэшируемый
объект отличается от текущего объекта (по таким параметрам, как
Content-Length, Content-MD5, ETag или Last-Modified), то кэш
ДОЛЖЕН обрабатывать содержимое как просроченное.
9.5 POST.
Метод POST используется для запроса, при котором адресуемый сервер
принимает объект, включенный в запрос, как новое подчинение
ресурса, идентифицированного запрашиваемым URI (Request-URI) в
строке запроса (Request-Line). POST разработан для того, чтобы
общим методом реализовать следующие функции:
o Аннотация существующих ресурсов;
o Регистрация сообщения на электронной доске объявлений
(bulletin board), в конференции новостей (newsgroup), списке
рассылки (mailing list), или подобной группе статей;
o Передача блока данных, например результат ввода в форме,
процессу обработки;
o Расширение базы данных посредством конкатенирующей операции
(append operation).
Фактически функция, выполняемая методом POST, определяется
сервером и обычно зависит от запрашиваемого URI (Request-URI).
Объект, передаваемый методом POST, относится к этому URI таким же
образом, как файл относится к каталогу, в котором он находится,
статья относится к конференции новостей (newsgroup), в которой она
зарегистрирована, а запись относится к базе данных.
Действие, выполняемое методом POST может не давать в качестве
результата ресурс, который можно было бы идентифицировать URI. В
этом случае, в зависимости от того, включает ли ответ объект,
описывающий результат, или нет, код состояния в ответе может быть
как 200 (OK), так и 204 (Нет содержимого, No Content).
Если ресурс был создан на первоначальном сервере, ответу СЛЕДУЕТ
содержать код состояния 201 (Создан, Created) и включать объект,
который описывает состояние запроса и ссылается на новый ресурс,
а также заголовок Location (смотрите раздел 14.30).
Ответы на этот метод не кэшируемы, если ответ не включает
соответствующие поля заголовка Cache-Control или Expires. Однако,
ответ с кодом состояния 303 (Смотреть другой, See Other) может
использоваться для перенаправления агента пользователя для
загрузки кэшируемого ресурса.
Запросы POST должны отвечать требованиям передачи сообщения,
изложенным в разделе 8.2.
9.6 PUT.
Запросы с методом PUT, которые содержат объект, сохраняются под
запрашиваемым URI (Request-URI). Если Request-URI обращается к уже
существующему ресурсу, включенный объект СЛЕДУЕТ рассматривать как
модифицированную версию объекта, находящегося на первоначальном
сервере. Если Request-URI не указывает на существующий ресурс, и
может интерпретироваться агентом пользователя как новый ресурс для
запросов, первоначальный сервер может создать ресурс с данным URI.
Если новый ресурс создан, то первоначальный сервер ДОЛЖЕН сообщить
агенту пользователя об этом посредством ответа с кодом состояния
201 (Создан, Created). Если существующий ресурс модифицирован, то
для указания успешного завершения запроса СЛЕДУЕТ послать ответ с
кодом состояния либо 200 (OK), либо 204 (Нет содержимого, No
Content). Если ресурс не может быть создан или изменен для
запрашиваемого URI (Request-URI), то СЛЕДУЕТ послать ответ,
отражающий характер проблемы. Получатель объекта НЕ ДОЛЖЕН
игнорировать заголовков Content-* (например Content-Range),
которых не понимает или не реализует, а ДОЛЖЕН в данном случае
возвратить ответ с кодом состояния 501 (Не реализовано, Not
Implemented).
Если запрос передается через кэш и запрашиваемый URI (Request-URI)
идентифицирует один или несколько кэшированных в настоящее время
объектов, то вхождения в кэш этих объектов должны обрабатываться
как просроченные. Ответы на этот метод не кэшируемы.
Фундаментальное различие между POST и PUT запросами, отражено в
различном значении запрашиваемого URI (Request-URI). URI в запросе
POST идентифицирует ресурс, который обрабатывает включенный
объект. Этим ресурсом может быть процесс, принимающий данные, шлюз
к некоторому другому протоколу, или отдельный объект, который
принимает аннотации (accepts annotations). Напротив, URI в запросе
PUT идентифицирует объект, включенный в запрос - агент
пользователя назначает данный URI включенному ресурсу, а сервер НЕ
ДОЛЖЕН пытаться применить запрос к некоторому другому ресурсу.
Если сервер желает применить запрос к другому URI, он ДОЛЖЕН
послать ответ с кодом 301 (Перемещен постоянно, Moved
Permanently); агент пользователя МОЖЕТ затем принять собственное
решение относительно переназначения запроса.
Одиночный ресурс МОЖЕТ быть идентифицирован несколькими различными
URI. Например, статья может иметь URI идентифицирующий "текущую
версию", который отличен от URI, идентифицирующего каждую
специфическую версию. В этом случае, запрос PUT на общий URI может
отразиться (may result) на нескольких других URI, определенных
сервером происхождения.
HTTP/1.1 не определяет каким образом метод PUT воздействует на
состояние первоначального сервера.
Запросы PUT должны подчиняться требованиям передачи сообщений,
изложенным в разделе 8.2.
9.7 DELETE.
Метод DELETE запрашивает первоначальный сервер об удалении
ресурса, идентифицируемого запрашиваемым URI (Request-URI). Этот
метод МОЖЕТ быть отменен человеческим вмешательством (или другими
средствами) на первоначальном сервере. Клиенту нельзя
гарантировать, что операция была выполнена, даже если код
состояния, возвращенный первоначальным сервером указывает на то,
что действие было завершено успешно. Однако, серверу НЕ СЛЕДУЕТ
отвечать об успешном выполнении, если во время ответа он
предполагает удалить ресурс или переместить его в недоступное
положение.
Успешному ответу СЛЕДУЕТ иметь код состояния 200 (OK), если ответ
включает объект, описывающий состояние, либо иметь код состояния
202 (Принято, Accepted), если действие еще не было произведено,
либо иметь код состояния 204 (Нет содержимого, No Content), если
ответ сообщает об успехе (OK), но не содержит объекта.
Если запрос передается через кэш и запрашиваемый URI (Request-URI)
идентифицирует один или несколько кэшированных в настоящее время
объектов, то вхождения их должны обрабатываться как просроченные.
Ответы на этот метод не кэшируемы.
9.8 TRACE.
Метод TRACE используется для вызова удаленного возврата сообщения
запроса на уровне приложения. Конечному получателю запроса СЛЕДУЕТ
отразить полученное сообщение обратно клиенту как тело объекта
ответа с кодом состояния 200 (OK). Конечным получателем является
либо сервер происхождения, либо первый прокси-сервер, либо первый
шлюз, получивший нулевое значение (0) в поле Max-Forwards в
запросе (см. раздел 14.31). Запрос TRACE НЕ ДОЛЖЕН содержать
объекта.
TRACE позволяет клиенту видеть, что получается на другом конце
цепочки запросов и использовать эти данные для тестирования или
диагностической информации. Значение поля заголовка Via (раздел
14.44) представляет особый интерес, так как оно действует как
след цепочки запросов. Использование поля заголовка Max-Forwards
позволяет клиенту ограничивать длину цепочки запросов, что
является полезным при тестировании бесконечных циклов в цепочке
прокси-серверов, пересылающих сообщения.
Если запрос успешно выполнен, то ответу СЛЕДУЕТ содержать все
сообщение запроса в теле объекта (entity-body), а Content-Type
следует быть равным "message/http". Ответы на этот метод НЕ
ДОЛЖНЫ кэшироваться.
10 Описания кодов состояния (Status Code Definitions).
Каждый код состояния, описанный ниже, включает описание метода
(или методов), за которым он может следовать и метаинформации,
требуемой в ответе.
10.1 1xx - Информационные коды.
Этот класс кодов состояния указывает предварительный (временный)
ответ, состоящий только из строки состояния (Status-Line) и
опциональных заголовков, и завершающийся пустой строкой. Так как
HTTP/1.0 не определял никаких 1xx кодов состояния, серверы НЕ
ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам, за исключением
экспериментальных условий.
10.1.1 100 Продолжать, Continue.
Клиент может продолжать запрос. Этот промежуточный ответ
используется, для того, чтобы сообщить клиенту, что начальная
часть запроса была получена и еще не отвергнута сервером. Клиенту
СЛЕДУЕТ продолжить посылку оставшихся данных запроса или, если
запрос уже был выполнен, игнорировать этот ответ. Сервер ДОЛЖЕН
послать заключительный ответ после того, как запрос будет
выполнен.
Сервер понимает и желает выполнить запрос клиента, если протокол
прикладной программы в этом соединении будет изменен на тот,
который указан в поле заголовка сообщения Upgrade (раздел 14.41).
Сервер переключит протокол на тот, который определен в поле
заголовка ответа Upgrade непосредственно после пустой строки,
которая завершает ответ с кодом состояния 101.
Протокол должен быть переключен только тогда, когда это принесет
выгоду. Например, переключение на более новую версию HTTP выгодно
по сравнения с использованием более старых версий, а переключение
на синхронный протокол реального времени может быть выгодно при
предоставлении ресурсов, которые используют такие возможности.
10.2 2xx - Успешные коды.
Этот класс кодов состояния указывает, что запрос клиента был
успешно получен, понят, и принят.
10.2.1 200 OK.
Запрос был удачно выполнен. Информация, возвращаемая с ответом
зависит от метода, используемого в запросе. Например:
GET в ответе представлен объект, соответствующий запрошенному
ресурсу;
HEAD в ответе представлены поля заголовка объекта
(entity-header), соответствующие запрошенному ресурсу. Тело
сообщения (message-body) отсутствует;
POST в ответе представлено описание объекта или содержится
результат действия;
TRACE в ответе представлен объект, содержащий сообщение запроса,
полученого конечным сервером.
10.2.2 201 Создан, Created.
Запрос был выполнен и в результате был создан новый ресурс. Новый
созданный ресурс может быть вызван по URI (одному или нескольким),
возвращенным в объекте ответа; наиболее специфический URL для
ресурса отдается в поле заголовка Location. Первоначальный сервер
ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если
действие не может быть выполнено немедленно, сервер должен
возвратить ответ с кодом состояния 202 (Принято, Accepted) вместо
201.
10.2.3 202 Принято, Accepted.
Запрос был принят для обработки, но обработка не была завершена.
В конечном счете запрос МОЖЕТ быть, а МОЖЕТ и не быть выполнен,
поскольку он МОЖЕТ быть отвергнут при фактической обработке.
Не имеется никакой возможности вторичной посылки кода состояния от
асинхронной операции типа этой.
Ответ с кодом состояния 202 преднамеренно уклончив. Цель его
состоит в том, чтобы позволить серверу принять запрос для
некоторого другого процесса (возможно пакетно-ориентированного
процесса, который выполняется только один раз в день) и не
требовать при этом, чтобы соединение агента пользователя с
сервером сохранялось до завершения процесса. Объекту,
возвращенному с этим ответом СЛЕДУЕТ содержать индикатор текущего
состояния запроса и либо ссылку на монитор состояния, либо
некоторую оценку времени, когда пользователь может ожидать
завершения выполнения запроса.
10.2.4 203 Не авторская информация, Non-Authoritative Information.
Возвращенная в заголовке объекта (entity-header) метаинформация -
это не оригинал, доступный на первоначальном сервере, а документ,
собранный из локальных копий или копий третьей стороны.
Представленный документ МОЖЕТ быть как подмножеством оригинальной
версии, так и содержать сведения, которые в ней не были
представлены. Например, включение локальной аннотирующей
информацию о ресурсе МОЖЕТ расширить метаинформацию, известную
первоначальному серверу. Использование этого кода состояния в
ответе не является необходимым, но может применяться тогда, когда
код состояния ответа отличен от 200 (OK).
10.2.5 204 Нет содержимого, No Content.
Сервер выполнил запрос, но нет никакой новой информации, которую
можно послать обратно. Если клиент - агент пользователя, ему НЕ
СЛЕДУЕТ изменять вид документа, который послужил причиной запроса.
Этот ответ предназначен прежде всего для того, чтобы позволить
вводить данные для действий, не изменяя вид активного документа
агента пользователя. Ответ МОЖЕТ включать новую метаинформацию в
форме заголовков объекта (entity-headers), которые СЛЕДУЕТ
добавить к документу, показываемому в настоящее время агентом
пользователя.
Ответ с кодом состояния 204 НЕ ДОЛЖЕН содержать тела сообщения, и,
таким образом, всегда завершается первой пустой строкой после
полей заголовка.
10.2.6 205 Сбросить содержимое, Reset Content.
Сервер выполнил запрос, и агенту пользователя СЛЕДУЕТ отменить
просмотр документа, который инициировал запрос. Этот ответ
предназначен прежде всего для того, чтобы позволить ввод данных,
осуществляемый пользователем, с последующей очисткой формы, в
которой сделан ввод, так, чтобы пользователь мог легко
инициировать следующее действие ввода. Ответ НЕ ДОЛЖЕН содержать
объект.
10.2.7 206 Частичное содержимое, Partial Content.
Сервер выполнил частичный GET запрос ресурса. Запрос должен
содержать поле заголовка Range (раздел 14.36), указывающее
желаемый диапазон. Ответ ДОЛЖЕН содержать либо поле заголовка
Content-Range (раздел 14.17), указывающее диапазон, включенный в
ответ, либо тип содержимого (Content-Type) должен быть равным
"multipart/byteranges", а поля Content-Range должны содержаться в
каждой части. Если "multipart/byteranges" не используется, поле
заголовка Content-Length в ответе ДОЛЖНО соответствовать
фактическому числу октетов (OCTETs), переданных в теле сообщения
(message-body).
Кэш, который не поддерживает заголовки Range и Content-Range НЕ
ДОЛЖЕН кэшировать ответы с кодом состояния 206.
10.3 3xx - Перенаправление.
Этот класс кодов состояния указывает, что для выполнения запроса
агенту пользователя необходимо придпринять дополнительное
действие. Требуемое действие МОЖЕТ быть выполнено агентом
пользователя без взаимодействия с пользователем, тогда и только
тогда, когда во втором запросе используется метод GET или HEAD.
Агенту пользователя НЕ СЛЕДУЕТ автоматически перенаправлять
запрос более 5 раз, так как такие переадресации обычно указывают
бесконечный цикл.
10.3.1 300 Множественный выбор, Multiple Choices.
Запрошенный ресурс имеет несколько представлений, и можно
использовать любое из перечисленных. Каждое представление имеет
свое расположение и информацию для агента по управлению диалогом
(раздел 12), представленную таким образом, что пользователь (или
агент пользователя) может выбрать наиболее подходящее
представление и перенаправить запрос к нему.
Если запрос был отличен от HEAD, то ответу СЛЕДУЕТ содержать
объект, включающий список характеристик и адресов, из которого
пользователь или агент пользователя может выбрать один наиболее
подходящий. Формат объекта определяется медиа типом, указанным в
поле заголовка Content-Type. В зависимости от формата и
возможностей агента пользователя, выбор наиболее подходящего
представления может выполняться автоматически. Однако, эта
спецификация не определяет какого-либо стандарта для
автоматического выбора.
Если сервер имеет представление по умолчанию (наиболее
предпочтительное), то ему СЛЕДУЕТ включить URL этого представления
в поле Location; агенты пользователя МОГУТ использовать значение
поля Location для автоматической переадресации. Этот ответ
является кэшируемым, если не обозначено иного.
10.3.2 301 Постоянно перенесен, Moved Permanently.
Запрошенному ресурсу был назначен новый постоянный URI, и любые
будущие ссылки на этот ресурс СЛЕДУЕТ выполнять, используя один из
возвращенных URI. Клиентам с возможностями редактирования связей
СЛЕДУЕТ автоматически переопределить ссылки на запрашиваемый URI
(Request-URI), используя одну или несколько новых ссылок,
возвращенных сервером в тех местах, где это возможно. Этот ответ
является кэшируемым, если не обозначено иного.
Если новый URI - это расположение, то ответу СЛЕДУЕТ содержать URL
в поле Location. Если метод запроса был не HEAD, то объекту ответа
СЛЕДУЕТ содержать короткое гипертекстовое примечание с
гиперссылкой на новый (или новые) URI.
Если код состояния 301 был получен в ответ на запрос, отличный от
GET или HEAD, агент пользователя НЕ ДОЛЖЕН автоматически
переназначать запрос, пока нет подтверждения пользователя, так как
иначе условия запроса изменятся.
Обратите внимание: При автоматическом переназначении запроса
POST после получения кода состояния 301, некоторые существующие
HTTP/1.0 агенты пользователя ошибочно изменят метод запроса на
GET.
10.3.3 302 Временно перемещен, Moved Temporarily.
Запрошенный ресурс временно находится под другим URI. Так как
переадресация может быть изменена в любой момент, клиенту СЛЕДУЕТ
продолжать использовать запрашиваемый URI (Request-URI) в будущих
запросах. Кэшируемость этого ответа зависит только от содержимого
полей заголовка Cache-Control или Expires (если этих полей нет, то
ответ не кэшируется).
Если новый URI - это расположение, то ответу СЛЕДУЕТ содержать URL
в поле Location. Если метод запроса был не HEAD, то объекту ответа
СЛЕДУЕТ содержать короткое гипертекстовое примечание с
гиперссылкой на новый (или новые) URI.
Если код состояния 302 был получен в ответ на запрос, отличный от
GET или HEAD, агент пользователя НЕ ДОЛЖЕН автоматически
переназначать запрос, пока нет подтверждения пользователя, так как
иначе условия запроса изменятся.
Обратите внимание: При автоматическом переназначении запроса
POST после получения кода состояния 302, некоторые существующие
HTTP/1.0 агенты пользователя ошибочно изменят метод запроса на
GET.
10.3.4 303 Смотреть другой, See Other.
Ответ на запрос может быть найден под другим URI и его СЛЕДУЕТ
запрашивать, используя метод GET для этого ресурса. Этот метод
существует прежде всего для того, чтобы производить вывод данных
активизированного методом POST сценария, используя перенаправление
агента пользователя на указанный ресурс. Новый URI - это не
ссылка, заменяющая первоначально запрошенный ресурс. Ответ с кодом
состояния 303 не кэшируем, но ответ на второй (переназначенный)
запрос МОЖЕТ быть кэширован.
Если новый URI - это расположение, то ответу СЛЕДУЕТ содержать URL
в поле Location. Если метод запроса был не HEAD, то объекту ответа
СЛЕДУЕТ содержать короткое гипертекстовое примечание с
гиперссылкой на новый (или новые) URI.
10.3.5 304 Не модифицирован, Not Modified.
Если клиент выполнил условный GET запрос, и доступ разрешен, но
документ не изменился, то серверу СЛЕДУЕТ ответить, используя этот
код состояния. Ответ НЕ ДОЛЖЕН содержать тела сообщения.
Ответ ДОЛЖЕН содержать следующие поля заголовка:
o Date
o ETag и/или Content-Location, если заголовок был бы послан в
ответе с кодом состояния 200 на этот же запрос
o Expires, Cache-Control, и/или Vary, если значение поля
(field-value) может отличаться от посланного в любом
предыдущем ответе для такого же варианта
Если условный GET использует строгое сравнение кэша (strong cache
validator) (смотреть раздел 13.3.3), ответу НЕ СЛЕДУЕТ содержать
других заголовков объекта (entity-headers). Иначе (то есть, если
условный GET использует слабое сравнение (weak validator)), ответ
НЕ ДОЛЖЕН содержать других заголовков объекта; это предотвращает
несогласованности между кэшированными телами объектов
(entity-bodies) и модифицированными заголовками.
Если ответ с кодом состояния 304 указывает объект, в настоящее
время не кэшированный, то кэш ДОЛЖЕН игнорировать ответ и
повторить запрос без условного выражения.
Если кэш использует полученный ответ с кодом состояния 304 для
модифицикации вхождения кэша, кэш ДОЛЖЕН модифицировать вхождение
так, чтобы отразить любые новые значения полей, данные в ответе.
Ответ с кодом состояния 304 НЕ ДОЛЖЕН включать тела сообщения
(message-body), и, таким образом, всегда завершается первой пустой
строкой после полей заголовка.
10.3.6 305 Используйте прокси-сервер, Use Proxy.
Обращение к запрошенному ресурсу ДОЛЖНО производиться через
прокси-сервер, указанный в поле Location. В поле Location указан URL прокси-сервера. Ожидается, что получатель повторит запрос
через прокси-сервер.
10.4 4xx - Коды ошибок клиента.
Класс кодов состояния 4xx предназначен для случаев, когда клиент,
возможно, допустил ошибку. За исключением ответа на запрос
HEAD, серверу СЛЕДУЕТ включить объект, содержащий объяснение
ошибочной ситуации, и объяснение, является ли она временной или
постоянной. Эти коды состояния применимы к любому методу запроса.
Агентам пользователя СЛЕДУЕТ показывать пользователю любой
включенный объект.
Обратите внимание: Если клиент посылает данные, то реализации
сервера, использующей TCP, следует гарантировать, что клиент
подтвердил получение пакета(ов), содержащего ответ, прежде чем
сервер закроет соединение. Если клиент продолжает посылать
данные серверу после закрытия соединения, TCP стек сервера
пошлет пакет сброса (RST) клиенту, а TCP стек клиента, в свою
очередь, может стереть клиентские неподтвержденные входные
буфера прежде, чем они будут прочитаны и интерпретированы
приложением HTTP.
10.4.1 400 Испорченный Запрос, Bad Request.
? Запрос не может быть понят сервером из-за malformed синтаксиса.
Клиенту НЕ СЛЕДУЕТ повторять запрос без модификаций.
10.4.2 401 Несанкционированно, Unauthorized.
Запрос требует установления подлинности пользователя. Ответ ДОЛЖЕН
включать поле заголовка WWW-Authenticate (раздел 14.46),
содержащее вызов (challenge), применимый к запрошенному ресурсу.
Клиент МОЖЕТ повторить запрос с подходящим полем заголовка
Authorization (раздел 14.8). Если запрос уже включает рекомендации
установления подлинности (Authorization credentials) в поле
Authorization, то ответ с кодом состояния 401 указывает, что в
установлении подлинности этим рекомендациям отказано. Если ответ
с кодом состояния 401 содержит тот же самый вызов, что и
предшествующий ответ, а агент пользователя уже делал попытку
установления подлинности по крайней мере один раз, то СЛЕДУЕТ
показать пользователю объект, который был дан в ответе, так как
? этот объект МОЖЕТ включать relevant диагностическую информацию.
Установление подлинности доступа в протоколе HTTP описывается в
разделе 11.
10.4.3 402 Требуется оплата, Payment Required.
Этот код зарезервирован для будущего использования.
10.4.4 403 Запрещено, Forbidden.
Сервер понял запрос, но отказывается выполнять его. Установление
подлинности (Authorization) не поможет, и запрос НЕ ДОЛЖЕН быть
повторен. Если метод запроса не HEAD и сервер желает указать,
почему запрос не был выполнен, ему СЛЕДУЕТ описать причину отказа
в объекте. Этот код состояния обычно используется, когда сервер
не желает указывать точную причину отказа, или когда никакой
другой ответ не подходит.
10.4.5 404 Не найден, Not Found.
Сервер не нашел ничего, соответствующего данному запрашиваемому
URI (Request-URI). Никак не сообщается является ли такое положение
временным или постоянным.
Если сервер не желает делать данную информацию доступной клиенту,
то вместо этого кода состояния может использоваться код состояния
403 (Запрещено, Forbidden). Код состояния 410 (Удален, Gone)
СЛЕДУЕТ использовать, если сервер знает через некоторый внутренне
конфигурируемый механизм, что старый ресурс более недоступен, но
не знает нового адреса для пересылки.
10.4.6 405 Метод не дозволен, Method Not Allowed.
Метод, определенный в строке запроса (Request-Line) не дозволено
применять для ресурса, идентифицированного запрашиваемым URI
(Request-URI). Ответ ДОЛЖЕН включать заголовок Allow, содержащий
список допустимых методов для запрошенного ресурса.
10.4.7 406 Не приемлем, Not Acceptable.
Ресурс, идентифицируемый запросом, имеет возможности генерации
только таких объектов ответа, которые имеют характеристики
содержимого (content characteristics), не согласующиеся с
заголовками приема (accept headers), представленными в запросе.
Если это был не запрос HEAD, то в ответ СЛЕДУЕТ включить объект,
содержащий список доступных характеристик объекта и адреса
(locations), из которых пользователь или агент пользователя может
выбрать наиболее подходящий. Формат объекта определеятся медиа
типом, представленным в поле заголовка Content-Type. В зависимости
от формата и возможностей агента пользователя, выбор наиболее
подходящего варианта может выполняться автоматически. Однако, эта
спецификация не определяет никакого стандарта для автоматического
выбора.
Обратите внимание: HTTP/1.1 серверы позволяют возвращать ответы,
которые не приемлемы согласно заголовкам приема (accept
headers), представленным в запросе. В некоторых случаях, это
может быть даже предпочтительно по сравнению с посылкой ответа
с кодом состояния 406. Агентам пользователя неплохо бы
рассматривать заголовки поступившего ответа, чтобы определить,
является ли он приемлемым. Если ответ недопустим, агенту
пользователя СЛЕДУЕТ временно остановиться, чтобы получить
больше данных и спросить пользователя о дальнейших действиях.
10.4.8 407 Требуется установление подлинности через прокси-сервер,
Proxy Authentication Required.
Этот код подобен коду 401 (Несанкционированно, Unauthorized), но
указывает, что клиент ДОЛЖЕН сначала установить свою подлинность
(authenticate) прокси-серверу. Прокси-сервер ДОЛЖЕН возвратить
поле заголовка Proxy-Authenticate (раздел 14.33), содержащее
вызов (challenge), применяемый прокси-сервером для запрошенного
ресурса. Клиент МОЖЕТ повторить запрос с подходящим полем
заголовка Proxy-Authorization (раздел 14.34). Установление
подлинности доступа в протоколе HTTP описывается в разделе 11.
10.4.9 408 Истекло время ожидания запроса, Request Timeout.
Клиент не произвел запрос в течение времени, которое сервер готов
ждать. Клиент МОЖЕТ повторить запрос без модификаций позже.
10.4.10 409 Конфликт, Conflict.
Запрос не был выполнен из-за конфликта с текущим состоянием
ресурса. Этот код позволяется только в ситуациях, когда ожидается,
что пользователь может решить конфликт и повторно передать запрос.
Телу ответа СЛЕДУЕТ содержать достаточное количество информации
для пользователя, чтобы он мог распознать источник конфликта. В
идеале, объект ответа должен включать достаточно информации для
пользователя или агента пользователя для решения проблемы; однако
это может не быть возможно, да и не требуется.
Конфликты, наиболее вероятно, будут возникать в ответ на запрос
PUT. Если используется версификация, и объект, который должен быть
помещен, включает изменения ресурса, которые находятся в
противоречии со сделанными раньше каким-либо запросом (третьей
стороны), сервер МОЖЕТ использовать ответ с кодом состояния 409,
чтобы показать, что он не может выполнить запрос. В этом случае,
объекту ответа СЛЕДУЕТ содержать список отличий двух версий в
формате, определенном полем заголовка ответа Content-Type.
10.4.11 410 Удален, Gone.
Запрошенный ресурс больше не доступен на сервере, и нет никакого
адреса для перенаправления запроса. Такое состояние СЛЕДУЕТ
рассматривать как постоянное. Клиентам с возможностями
редактирования гиперсвязей СЛЕДУЕТ удалить ссылки на запрашиваемый
URI (Request-URI) после одобрения пользователем. Если сервер не
знает, или не может определить, является ли такое положение
постоянным или нет, то ему СЛЕДУЕТ вместо этого кода использовать
код состояния 404 (Не найден, Not Found). Этот ответ является
кэшируемым, если не обозначено иного.
Ответ с кодом состояния 410 предназначен прежде всего для того,
чтобы помочь в сопровождении WWW, уведомляя получателя, что ресурс
преднамеренно недоступен и что владельцы сервера желают, чтобы
удаленные связи, указывающие на этот ресурс были удалены. Такое
случается в основном для ограниченных по времени, рекламных
сервисов и для ресурсов, принадлежащих личностям, больше не
занимающимся сайтом. Не обязательно отмечать все постоянно
недоступные ресурсы как "удаленные" ("gone") или хранить запись в
течение любого отрезка времени - это предоставляется на усмотрение
владельца сервера.
10.4.12 411 Требуется длина, Length Required.
Сервер отказывается принимать запрос с неопределенным
Content-Length. Клиент МОЖЕТ повторить запрос, если добавит
допустимое поле заголовка Content-Length, содержащее длину тела
сообщения (message-body) в сообщении запроса.
Предусловие, представленное одним или несколькими полями заголовка
запроса (request-header), оказалось ложным при проверке сервером.
Этот код ответа позволяет клиенту поместить предусловия на текущую
метаинформацию ресурса (данные полей заголовка) и, таким образом,
предотвратить применение запрошенного метода к ресурсу, отличному
от того, для которого предназначен метод.
10.4.14 413 Объект запроса слишком большой, Request Entity Too Large.
Сервер отказывается обрабатывать запрос, потому что объект запроса
больше, чем сервер желает или способен обработать. Сервер может
закрыть соединение, чтобы не дать клиенту возможность продолжить
запрос.
Если это временное состояние, то серверу СЛЕДУЕТ включить поле
заголовка Retry-After для указания времени, через которое клиент
может снова повторить запрос.
10.4.15 414 URI запроса слишком длинный, Request-URI Too Long.
Сервер отказывается обслуживать запрос, потому что запрашиваемый
URI (Request-URI) длиннее, чем сервер желает интерпретировать. Это
редкое состояние, которое, по всей вероятности, происходит только
тогда, когда клиент неправильно преобразовал запрос POST к запросу
GET с длинной информацией запроса, либо когда клиент попал в
"черную дыру" URL перенаправления (например, перенаправленный URL
префикс указывает на свой суффикс), или когда на сервер
производится нападение клиентом, пытающимся эксплуатировать
лазейки в секретности, имеющиеся в некоторых серверах,
использующих буфера фиксированной длины для чтения или
манипулирования с запрашиваемым URI (Request-URI).
10.4.16 415 Неподдерживаемый медиа тип, Unsupported Media Type.
Сервер отказывается обслуживать запрос, потому что объект запроса
находится в формате, не поддерживаемом запрошенным ресурсом для
запрошенного метода.
10.5 5xx - Коды ошибок сервера.
Коды состояния, начинающиеся с цифры "5" указывают случаи, в
которых сервер знает, что допустил ошибку или неспособен выполнить
запрос. Отвечая на запрос, за исключением запроса HEAD, серверу
СЛЕДУЕТ включить объект, содержащий объяснение ошибочной ситуации
и информацию, является ли это положение временным или постоянным.
Агентам пользователя СЛЕДУЕТ показывать пользователю любой
включенный объект. Эти коды состояния применимы к любому методу
запроса.
10.5.1 500 Внутренняя ошибка сервера, Internal Server Error.
Сервер столкнулся с непредвиденным условием, которое не позволяет
ему выполнить запрос.
10.5.2 501 Не реализовано, Not Implemented.
Сервер не поддерживает функциональные возможности, требуемые для
выполнения запроса. Этот ответ соответствует состоянию, когда
сервер не распознает метод запроса и не способен обеспечитиь его
для любого ресурса.
10.5.3 502 Ошибка шлюза, Bad Gateway.
Сервер, действуя в качестве шлюза или прокси-сервера, получил
недопустимый ответ от следующего сервера в цепочке запросов, к
которому обратился при попытке выполнить запрос.
10.5.4 503 Сервис недоступен, Service Unavailable.
Сервер в настоящее время не способен обработать запрос из-за
временной перегрузки или обслуживания сервера. Это временное
условие, которое будет облегчено после некоторой задержки.
Если известна продолжительность задержки, она может быть указана
в заголовке Retry-After. Если Retry-After не присутствует в
ответе, клиенту СЛЕДУЕТ обрабатывать этот ответ как ответ с кодом
500.
Обратите внимание: существование кода состояния 503 не
подразумевает, что сервер должен использовать его, когда
перегружен. Некоторые сервера могут просто закрывать соединение.
10.5.5 504 Истекло время ожидания от шлюза, Gateway Timeout.
Сервер, действуя в качестве шлюза или прокси-сервера, не получил
своевременного ответа от следующего сервера в цепочке запросов, к
которому обратился при попытке выполнить запрос.
10.5.6 505 Не поддерживаемая версия HTTP, HTTP Version Not Supported.
Сервер не поддерживает, или отказывается поддерживать, версию HTTP
протокола, которая используется в сообщении запроса. Сервер
указывает, что не способен или не желает выполнять запрос,
используя ту же самую major версию, что и клиент, как описано в
разделе 3.1, в других сообщениях. Ответу СЛЕДУЕТ содержать объект,
описывающий, почему эта версия не поддерживается, и какие другие
протоколы поддерживаются этим сервером.
11 Установление подлинности доступа (Access Authentication).
HTTP обеспечивает для установления подлинности простой механизм
вызов-ответ (challenge-response), который МОЖЕТ использоваться
сервером для вызова (challenge) клиентского запроса, а клиентом
для предоставления опознавательной информации (authentication
information). Он использует расширяемую, не чувствительную к
регистру лексему идентификации схемы установления подлинности
(authentication scheme) и отделенный запятой список пар
атрибут-значение (attribute-value), которые представляют
параметры, необходимые для установления подлинности с
использованием этой схемы.
auth-scheme = token
auth-param = token "=" quoted-string
Сообщение ответа с кодом 401 (Несанкционирован, Unauthorized)
используется первоначальным сервером для вызова (challenge)
установления подлинности (authorization) агентом пользователя.
Этот ответ ДОЛЖЕН содержать поле заголовка WWW-Authenticate,
включающее по крайней мере один вызов (challenge), применимый к
запрошенному ресурсу.
Атрибут области (realm) (не чувствительный к регистру) требуется
для всех схем установления подлинности, которые выдают вызов
(challenge). Значение аттрибута realm (чувствительное к регистру),
в комбинации с каноническим корневым URL (смотреть раздел 5.1.2)
сервера, к которому обращен запрос, определяет область защиты
(protection space). Эти области позволяют разбивать защищенные
ресурсы сервера на множество областей, каждая из которых имеет
собственную опознавательную схему и/или базу данных установления
подлинности (authorization database). Значение realm - строка,
вообще говоря назначенная первоначальным сервером, которая может
иметь дополнительную семантику, специфическую для схемы
установления подлинности (authentication scheme).
Агент пользователя, который хочет доказать свою подлинность
серверу, обычно, но не обязательно, МОЖЕТ это сделать после
получения ответа с кодом состояния 401 или 411, включив поле
заголовка Authorization в запрос. Значение поля Authorization
состоит из рекомендаций (credentials), содержащих информацию
установления подлинности (authentication information) агента
пользователя для области (realm) запрошенного ресурса.
Область (domain), над которой рекомендации (credentials) могут
автоматически применяться агентом пользователя, определена
областью защиты (protection space). Если подлинность была
установлена предшествующим запросом, то эти же рекомендации
(credentials) МОГУТ использоваться многократно во всех других
запросах внутри этой области защиты (protection space) в течении
времени, определенного схемой установления подлинности,
параметрами, и/или установками пользователя. Если схемой
установления подлинности не определено иного, то одиночная область
защиты (protection space) не может простираться шире области
сервера (the scope of its server).
Если сервер не желает принимать рекомендации (credentials),
посланные в запросе, то ему СЛЕДУЕТ возвратить ответ с кодом 401
(Несанкционирован, Unauthorized). Ответ ДОЛЖЕН включать поле
заголовка WWW-Authenticate, содержащее (возможно новый) вызов
(challenge), применимый к запрошенному ресурсу, и объект,
объясняющий отказ.
Протокол HTTP не ограничивает приложения использованием этого
простого механизма вызов-ответ (challenge-response) для
установления подлинности доступа. МОЖНО использовать
дополнительные механизмы, такие как шифрование на транспортном
уровне или формирование пакета сообщения (message encapsulation)
с дополнительными полями заголовка, определяющими информацию
установления подлинности. Однако эти дополнительные механизмы не
определены в этой спецификации.
Прокси-сервера ДОЛЖНЫ быть полностью прозрачны для установления
подлинности агента пользователя. То есть они ДОЛЖНЫ пересылать
заголовки WWW-Authenticate и Authorization нетронутыми и
следовать правилам раздела 14.8.
HTTP/1.1 позволяет клиенту передавать информацию установления
подлинности для и от прокси-сервера посредством заголовков
Proxy-Authenticate и Proxy-Authorization.
"Базовая" схема установления подлинности основана на том, что
агент пользователя должен доказывать свою подлинность при помощи
идентификатора пользователя (user-ID) и пароля (password) для
каждой области (realm). Значению области (realm) следует быть
непрозрачной (opaque) строкой, которую можно проверять только на
равенство с другими областями на этом сервере. Сервер обслужит
запрос, только если он может проверить правильность идентификатора
пользователя (user-ID) и пароля (password) для защищенной области
(protection space) запрошенного URI (Request-URI). Никаких
опциональных опознавательных параметров нет.
После получения запроса на URI, находящийся в защищаемой области
(protection space), сервер МОЖЕТ ответить вызовом (challenge),
подобным следующему:
WWW-Authenticate: Basic realm="WallyWorld"
где "WallyWorld" - строка, назначенная сервером, которая
идентифицирует область защиты запрашиваемого URI (Request-URI).
Чтобы получить права доступа, клиент посылает идентификатор
пользователя (userid) и пароль (password), разделенные одним
символом двоеточия (":"), внутри base64-кодированной строки
рекомендаций (credentials).
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64-кодированный [7] user-pass,
за исключением не ограниченных 76
символами в строке>
user-pass = userid ":" password
userid = *<TEXT не содержащий ":">
password = *TEXT
Userid может быть чувствителен к регистру.
Если агент пользователя хочет послать идентификатор пользователя
(userid) "Aladdin", и пароль (password) "open sesame", он будет
использовать следующее поле заголовка:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Соглашения о защите, связанные с базовой схемой установления
подлинности, смотрите в разделе 15.
Обзорное установление подлинности для HTTP определяется в
RFC 2069 [32].
12 Обсуждение содержимого (Content Negotiation).
Большинство HTTP ответов включают объект, который содержит
информацию, предназначенную для интерпретации пользователем.
Естественно желание обеспечить пользователя "лучшим доступным"
объектом, соответствующим запросу. К сожалению для серверов и
кэшей, не все пользователи имеют одиннаковые предпочтения, и не
все агенты пользователя одинаково способны к визуализации всех
типов объектов. По этой причине, HTTP имеет средства для
нескольких механизмов "обсуждения содержимого" - процесса выбора
самого лучшего представления для данного ответа, когда доступно
несколько представлений.
Обратите внимание: Это не вызывается "обсуждение формата"
("format negotiation"), потому что альтернативные представления
могут иметь одиннаковый медиа тип, но использовать различные
возможности этого типа, иметь разные языки и т.д.
Любой ответ, содержащий тело объекта (entity-body) МОЖЕТ быть
темой обсуждения, включая ошибочные ответы.
Имеются два вида обсуждения содержимого, которые возможны в HTTP:
управляемое сервером и управляемое агентом обсуждение. Эти два
вида обсуждения независимы, и, таким образом, могут использоваться
отдельно или вместе. Один метод использования их вместе,
упоминаемый как прозрачное обсуждение, происходит, когда кэш
использует информацию обсуждения, управляемого агентом,
предоставляя ее первоначальному серверу, для обеспечения
управляемого сервером обсуждения при последующих запросах.
12.1 Управляемое сервером обсуждение.
Обсуждение называется управляемым сервером, если выбор самого
лучшего представления для ответа произведен алгоритмом,
размещенным на сервере. Выбор основан на доступных представлениях
ответа (они могут различаться по нескольким характеристикам;
например языку, кодированию содержимого (content-coding), и т.д.)
и содержании специфических полей заголовка в сообщении запроса,
или на другой информации, имеющей отношение к запросу (такой как
сетевой адрес клиента).
Управляемое сервером обсуждение выгодно, когда алгоритм выбора из
числа доступных представлений трудно описать агенту пользователя,
или когда сервер желает послать "лучшее предположение" клиенту
одновременно с первым ответом (надеясь избежать задержки пересылки
туда и обратно последующего запроса, если "лучшее предположение"
устроит пользователя). Чтобы улучшить предположение сервера,
агент пользователя МОЖЕТ включать поля заголовка запроса (Accept,
Accept-Language, Accept-Encoding, и т.д.), которые описывают
предпочтительный ответ.
Управляемое сервером обсуждение имеет недостатки:
1. Сервер не может точно определить, что могло бы быть "самым
лучшим" для данного пользователя, так как это требует полного
знания, как возможностей агента пользователя, так и целей
использования ответа (например, пользователь хочет
просматривать его на экране или печатать на бумаге?).
2. Наличие описания возможностей агента пользователя в каждом
запросе может быть очень неэффективным (при условии, что
только небольшой процент ответов имеет несколько
представлений) и потенциально нарушает секретность
пользователя.
3. Оно усложняет реализацию первоначального сервера и алгоритмов
генерации ответов на запрос.
4. Оно может ограничивать способность общего кэша использовать
один и тот же ответ для запросов нескольких пользователей.
HTTP/1.1 включает следующие поля заголовка запроса
(request-header), которые обеспечивают управляемое сервером
обсуждение посредством описания возможностей агента пользователя
и предпочтений самого пользователя: Accept (раздел 14.1),
Accept-Charset (раздел 14.2), Accept-Encoding (раздел 14.3),
Accept-Language (раздел 14.4), and User-Agent (раздел 14.42).
Однако первоначальный сервер не ограничен этим и МОЖЕТ изменить
ответ, основываясь на любом аспекте запроса, включая информацию,
которая не содержится в полях заголовка запроса или информацию из
расширенных полей заголовка, не определенных в этой спецификации.
Первоначальный сервер HTTP/1.1 ДОЛЖЕН включать соответствующее
поле заголовка Vary (раздел 14.43) в любой кэшируемый ответ,
основанный на управлямом сервером обсуждении. Поле заголовка Vary
описывает характеристики, которые могут меняться в ответе (то есть
характеристики, согласно которым первоначальный сервер выбирает
"наилучший" ответ из нескольких представлений).
Общие HTTP/1.1 кэши ДОЛЖНЫ распознать поле заголовка Vary, если
он присутствует в ответе, и отвечать требованиям, описанным в
разделе 13.6, который описывает взаимодействия между кэшированием
и обсуждением содержимого.
12.2 Управляемое агентом обсуждение.
При управляемом агентом обсуждении, выбор лучшего представления
ответа выполняется агентом пользователя после получения начального
ответа первоначального сервера. Выбор основан на списке доступных
представлений ответа, включенном в поля заголовка (эта
спецификация резервирует имя поля Alternates, как описано в
приложении 19.6.2.1) или тело объекта начального ответа. Каждое
представление идентифицируется собственным URI. Выбор
представления может выполняться автоматически (если агент
пользователя способен это сделать) или вручную пользователем из
сгенерированного (возможно гипертекстового) меню.
Управляемое агентом обсуждение выгодно, когда ответ варьируется по
общеиспользуемым характеристикам (таким как тип, язык, или
кодирование), когда первоначальный сервер не способен определить
возможности агента пользователя путем исследования запроса, и
обычно при использовании общих кэшей для распределения нагрузки
на сервер и уменьшения использования сети.
Управляемое агентом обсуждение страдает тем, что для получения
самого лучшего альтернативного представления требуется второй
запрос. Этот второй запрос эффективен только тогда, когда
используется кэширование. Кроме того, эта спецификация не
определяет никакого механизма для обеспечения автоматического
выбора, хотя также и не предотвращает разработку такого механизма
в качестве расширения и использования в HTTP/1.1.
HTTP/1.1 определяет коды состояния 300 (Множественный выбор,
Multiple Choices) и 406 (Не приемлем, Not Acceptable) для
обеспечения управляемого агентом обсуждения, когда сервер не
желает или не способен обеспечить изменение ответа, используя
управляемое сервером обсуждение.
12.3 Прозрачное обсуждение.
Прозрачное обсуждение - это комбинация управляемого сервером и
управляемого агентом обсуждения. Когда кэш обеспечен списком
доступных представлений ответа (как при управляемом агентом
обсуждении) и изменяющиеся характеристики полностью поняты кэшем,
тогда он способен выполнять управляемое сервером обсуждение
последующих запросов этого же ресурса от имени первоначального
сервера.
Прозрачное обсуждение имеет то преимущество, что работа по
обсуждению распределяется. Когда кэш способен правильно
предположить нужный ответ сокращается работа, которая раньше
требовалась от первоначального сервера и не происходит задержки
второго запроса, как при управляемом агентом обсуждении.
Эта спецификация не определяет никакого механизма прозрачного
обсуждения, хотя также и не предотвращает разработку такого
механизма в качестве расширения и использования в HTTP/1.1.
HTTP/1.1 кэш, выполняющий прозрачное обсуждение ДОЛЖЕН включать
поле заголовка Vary (определяющее параметры, которые могут
варьироваться) в ответ, если он кэшируем, чтобы гарантировать
правильную интерпретацию всеми HTTP/1.1 клиентами. Информацию
управляемого агентом обсуждения, представленную первоначальным
сервером, СЛЕДУЕТ включать в ответ при прозрачном обсуждении.
