страница №1
RFC 2068. Протокол передачи гипертекста — HTTP/1.1 (перевод)
Network Working Group R. Fielding
Request for Comments: 2068 UC Irvine
Category: Standards Track J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
Январь 1997
ПРОТОКОЛ ПЕРЕДАЧИ ГИПЕРТЕКСТА — HTTP/1.1
О переводе.
Эдесь представлен перевод документа RFC 2068 на русский язык. При
переводе я пользовался личным опытом и здравым смыслом, поэтому в
некоторых местах читатель, знакомый с оригиналом, может заметить
несущественные отличия. Я изо всех сил пытался придать удобочитаемый
вид, но в некоторых местах вы встретите предложения, написанные
"криво" (это связано либо с "техничностью" текста, либо с моими
проблемами в русском языке). Убедительная просьба : если
встретите опечатки, ошибки, или у вас появятся предложения по
улучшению отдельных фраз или целых фрагментов - сообщите мне по
адресу Leshik@omsk.com .
Я отдаю себе отчет в том, что некоторые термины, возможно,
переведены некорректно. При сомнениях я добавлял английские термины
в круглых скобках. Например: запрос (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 HTTP URL .........................................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 и передаваемых по соединению.
Запрос (request)
Любое HTTP сообщение, содержащее запрос, определяемый в разделе 5.
Ответ (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"
допускает либо один, либо два повторения.
[правило]
[rule]
В квадратные скобки заключают опциональные элементы; "[foo bar]"
эквивалентно "*1(foo bar)".
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].
OCTET = <любая 8-битная последовательность данных>
CHAR = <любой US-ASCII символ (октеты 0 - 127)>
UPALPHA = <любой US-ASCII символ верхнего регистра
"A".."Z">
LOALPHA = <любой US-ASCII символ нижнего регистра
"a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <любая US-ASCII цифра "0".."9">
CTL = <любой US-ASCII управляющий символ (октеты
0 - 31) и DEL (127)>
CR = <US-ASCII CR, возврат каретки (13)>
LF = <US-ASCII LF, перевод строки (10)>
SP = <US-ASCII SP, пробел (32)>
HT = <US-ASCII HT, метка горизонтальной
табуляции (9)>
<"> = <US-ASCII двойные кавычки (34)>
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>
Шестнадцатеричные цифры используются некоторыми элементами
протокола.
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Многие значения полей заголовка HTTP/1.1 состоят из слов,
разделенных LWS или специальными символами. Эти специальные символы
ДОЛЖНЫ находиться в цитируемой строке (quoted string), чтобы быть
использованными в качестве значения параметра.
token = 1*<любой CHAR за исключением CTLs или
tspecials>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
В некоторые поля 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 ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <любой OCTET за исключением ALPHA, DIGIT,
reserved, extra, safe, и unsafe>
Полную информацию относительно синтаксиса и семантики 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.
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
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.
Пр...
