Протокол HTTP 1.1

Протокол HTTP 1.1

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

ЗАЧЕТНАЯ РАБОТА

ПО

ДИСЦИПЛИНЕ

«Информационно-вычислительные сети»

НА ТЕМУ

«Протокол HTTP 1.1»

|Работу выполнил: |Студент 5-го курса |

| |факультета Кибернетики |

| |группы ИО-1-97 Фроловичев|

| |Сергей |

|Преподаватель: |Дешко И.П. |

МОСКВА 2002 г.

Оглавление

1. Введение. 5

1.1. Назначение 5

1.3 Терминология. 5

2. Общее описание. 8

3. Параметры протокола. 11

3.1 Версия HTTP. 11

3.2 Универсальный Идентификатор Ресурса (URI). 12

3.2.1 Общий синтаксис. 12

3.2.2 HTTP URL. 13

3.2.3 Сравнение URI. 13

3.3 Форматы даты/времени. 14

3.3.1 Полная дата. 14

3.3.2 Разность секунд (delta seconds). 15

3.4 Кодовые таблицы (character sets). 15

3.5 Кодирования содержимого (content codings). 15

3.6 Кодирования передачи (Transfer Codings). 16

3.7 Медиатипы (Media Types). 17

3.7.1 Канонизация и предопределенные значения типа text. 18

3.7.2 Типы Multipart. 19

3.8 Маркеры продуктов (Product Tokens). 19

3.9 Величины качества (Quality Values). 20

3.10 Метки языков (Language Tags). 20

3.11 Метки объектов (Entity Tags). 21

3.12 Единицы измерения диапазонов (Range Units). 21

4. HTTP сообщение (HTTP Message). 22

4.1 Типы сообщений. 22

4.2 Заголовки сообщений. 22

4.3 Тело cообщения. 23

4.4 Длина сообщения. 24

4.5 Общие поля заголовка. 25

5. Запрос (Request). 25

5.1 Строка запроса (Request-Line). 25

5.1.1 Метод (Method). 25

5.1.2 URI запроса (Request-URI). 26

5.2 Ресурс, идентифицируемый запросом. 27

5.3 Поля заголовка запроса. 28

6 Ответ (Response). 28

6.1 Строка состояния (Status-Line). 28

6.1.1 Код состояния и поясняющая фраза. 28

6.2 Поля заголовка ответа. 30

7 Объект (Entity). 30

7.1 Поля заголовка объекта. 30

7.2 Тело объекта. 31

7.2.1 Тип. 31

7.2.2 Длина. 32

8 Соединения (Connections). 32

8.1 Постоянные соединения (Persistent Connections). 32

8.1.1 Цель. 32

8.1.2 Общее описание. 32

8.1.2.1 Обсуждение (Negotiation). 33

8.1.2.2 Конвейерная обработка (Pipelining). 33

8.1.3 Прокси-сервера (Proxy Servers). 33

8.1.4 Практические соображения. 34

8.2 Требования к передаче сообщений. 34

9 Определения методов. 36

9.1 Безопасные и идемпотентные методы. 36

9.1.1 Безопасные методы. 36

9.1.2 Идемпотентные методы. 37

9.2 OPTIONS. 37

9.3 GET. 38

9.4 HEAD. 38

9.5 POST. 38

9.6 PUT. 39

9.7 DELETE. 40

9.8 TRACE. 41

10 Определение кодов состояния. 41

10.1 1xx - Информационные коды. 41

10.1.1 100 Продолжать, Continue. 41

10.1.2 101 Переключение протоколов, Switching Protocols 42

10.2 2xx - Успешные коды. 42

10.2.1 200 OK. 42

10.2.2 201 Создан, Created. 42

10.2.3 202 Принято, Accepted. 43

10.2.4 203 Не авторская информация, Non-Authoritative Information. 43

10.2.5 204 Нет содержимого, No Content. 43

10.2.6 205 Сбросить содержимое, Reset Content. 43

10.2.7 206 Частичное содержимое, Partial Content. 44

10.3 3xx - Перенаправление. 44

10.3.1 300 Множественный выбор, Multiple Choices. 44

10.3.2 301 Постоянно перемещен, Moved Permanently. 45

10.3.3 302 Временно перемещен, Moved Temporarily. 45

10.3.4 303 Смотреть другой, See Other. 45

10.3.5 304 Не модифицирован, Not Modified. 46

10.3.6 305 Используйте прокси-сервер, Use Proxy. 46

10.4 4xx - Коды ошибок клиента. 47

10.4.1 400 Испорченный Запрос, Bad Request. 47

10.4.2 401 Несанкционированно, Unauthorized. 47

10.4.3 402 Требуется оплата, Payment Required. 47

10.4.4 403 Запрещено, Forbidden. 47

10.4.5 404 Не найден, Not Found. 48

10.4.6 405 Метод не допустим, Method Not Allowed. 48

10.4.7 406 Не приемлем, Not Acceptable. 48

10.4.8 407 Требуется установление подлинности через прокси-сервер, Proxy

Authentication Required. 48

10.4.9 408 Истекло время ожидания запроса, Request Timeout. 49

10.4.10 409 Конфликт, Conflict. 49

10.4.11 410 Удален, Gone. 49

10.4.12 411 Требуется длина, Length Required. 50

10.4.13 412 Предусловие неверно, Precondition Failed. 50

10.4.14 413 Объект запроса слишком большой, Request Entity Too Large.

50

10.4.15 414 URI запроса слишком длинный, Request-URI Too Long. 50

10.4.16 415 Неподдерживаемый медиатип, Unsupported Media Type. 50

10.5 5xx - Коды ошибок сервера. 51

10.5.1 500 Внутренняя ошибка сервера, Internal Server Error. 51

10.5.2 501 Не реализовано, Not Implemented. 51

10.5.3 502 Ошибка шлюза, Bad Gateway. 51

10.5.4 503 Сервис недоступен, Service Unavailable. 51

10.5.5 504 Истекло время ожидания от шлюза, Gateway Timeout. 51

10.5.6 505 Не поддерживаемая версия HTTP, HTTP Version Not Supported.

52

11 Установление подлинности доступа (Access Authentication). 52

11.1 Базовая схема установления подлинности (Basic Authentication Scheme).

53

11.2 Обзорная схема установления подлинности (Digest Authentication

Scheme) [1]. 54

13 Кэширование в HTTP. 54

13.1 Общая информация о кэшировании. 55

13.1.1 Правильность кэша. 55

13.1.2 Предупреждения. 56

13.1.3 Механизмы управления кэшем (Cache-control Mechanisms). 57

13.1.4 Явные предупреждения агента пользователя. 57

13.1.5 Исключения из правил и предупреждений. 57

13.1.6 Контролируемое клиентом поведение. 58

13.2 Модель устаревания. 58

13.2.1 Устаревание, указанное сервером. 58

13.2.2 Эвристическое устаревание. 59

13.2.3 Вычисление возраста. 59

13.2.4 Вычисление устаревания. 61

13.2.5 Устранение противоречий в значениях устаревания. 62

13.2.6 Устранение противоречий между несколькими ответами. 62

13.3 Модель проверки достоверности (validation model). 63

Библиографический список 65

1. Введение.

Протокол передачи гипертекста (HTTP) - протокол прикладного уровня для

распределенных, совместных, многосредных информационных систем. HTTP

используется в World Wide Web (WWW) начиная с 1990 года. Первой версией

HTTP, известной как HTTP/0.9, был простой протокол для передачи

необработанных данных через Интернет. По определению RFC 1945 HTTP/1.0 был

улучшением этого протокола, допускал MIME-подобный формат сообщений,

содержащий метаинформацию о передаваемых данных и имел модифицированную

семантику запросов/ответов. Однако HTTP/1.0 недостаточно учитывал

особенности работы с иерархическими прокси-серверами (hierarchical

proxies), кэшированием, постоянными соединениями, и виртуальными хостами

(virtual hosts). Кроме того, быстрый рост числа не полностью совместимых с

протоколом HTTP/1.0 приложений, потребовал введения новой версии протокола,

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

привести эти приложения к единому стандарту.

Список RFC относящийся к рассмотренным в данной работе вопросам,

приведен в разделе «Библиографический список».

1.1. Назначение

Протокол HTTP/1.1 содержит более строгие требования, чем HTTP/1.0,

гарантирующие более надежную работу.

Большие информационные системы требуют большего количества

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

и модификацию данных при помощи внешних интерфейсов. HTTP предоставляет

открытый (open-ended) набор методов, которые основаны на системе ссылок,

которые обеспечиваются URI (Универсальными Идентификаторами Ресурсов). URI

могут идентифицировать как расположение (URL), так и имя (URN) ресурса, к

которому применяется данный метод. Сообщения передаются в формате,

подобному используемому электронной почтой согласно определениям MIME

(Многоцелевых Расширений Электронной Почты).

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

пользователей (user agents) и прокси-серверами/шлюзами (proxies/gateways)

или другими Интернет-сервисами, включая такие как SMTP, NNTP, FTP, Gopher и

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

ресурсам для разнообразных приложений.

1.3 Терминология.

- Соединение (connection).

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

программами с целью связи.

- Сообщение (message).

Основной модуль HTTP связи, состоящей из структурной

последовательности октетов, соответствующих синтаксису протокола и

передаваемых по соединению.

- Запрос (request)

Любое HTTP сообщение, содержащее запрос.

- Ответ (response).

Любое HTTP сообщение, содержащее ответ.

- Ресурс (resource).

Сетевой объект данных или сервис, который может быть идентифицирован

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

на нескольких языках, в разных форматах данных, иметь различный размер

или различную разрешающую способность) или различаться по другим

параметрам.

- Объект (entity).

Информация, передаваемая в качестве полезной нагрузки запроса или

ответа. Объект состоит из метаинформации в форме полей заголовка

объекта и содержания в форме тела объекта.

- Представление (representation).

Объект включенный в ответ, и подчиняющийся обсуждению содержимого

(Content Negotiation). Может существовать несколько представлений,

связанных со специфическими состояниями ответа.

- Обсуждение содержимого (content negotiation).

Механизм для выбора соответствующего представления во время

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

обсуждено (включая ошибочные ответы).

- Вариант (variant).

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

в данный момент. Каждое из этих представлений называется "вариант".

Использование термина "вариант" не обязательно подразумевает, что

ресурс подчинен обсуждению содержимого.

- Клиент (client)

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

- Агент пользователя (user agent).

Клиент, который инициирует запрос. Как правило браузеры, редакторы,

роботы (spiders), или другие инструментальные средства пользователя.

- Сервер (server).

Приложение, которое слушает соединения, принимает запросы на

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

как клиентом, так и сервером; наше использование данного термина

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

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

Аналогично, любой сервер может действовать как первоначальный сервер

(origin server), прокси-сервер (proxy), шлюз (gateway) или туннель

(tunnel), изменяя поведение, основываясь на характере каждого запроса.

- Первоначальный сервер (origin server).

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

создан.

- Прокси-сервер (proxy).

Программа-посредник, которая действует и как сервер, и как клиент с

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

обслуживаются прокси-сервером, или пересылаются им, возможно с

изменениями. Прокси-сервер, согласно этой спецификации, должен

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

- Шлюз (gateway).

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

сервера. В отличие от прокси-сервера, шлюз получает запросы в качестве

первоначального сервера для запрошенного ресурса; клиент запроса может

не знать, что он соединяется со шлюзом.

- Туннель (tunnel).

Программа-посредник, которая поддерживает соединение. Один раз

созданный, туннель не рассматривается как часть HTTP связи, хотя

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

прекращает существовать, когда оба конца соединения закрываются.

- Кэш (cache).

Локальная память, в которой программа хранит сообщения-ответы, и в

которой располагается подсистема, управляющая хранением, поиском и

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

сохранены, чтобы уменьшить время ответа и загрузку сети (траффик) при

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

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

туннель.

- Кэшируемый (cachable).

Ответ является кэшируемым, если кэшу разрешено сохранить копию

ответного сообщения для использования при ответе на последующие

запросы. Даже если ресурс кэшируем, могут существовать дополнительные

ограничения на использование кэшем сохраненной копии для исходного

запроса.

- Непосредственный (first-hand).

Ответ считается непосредственным, если он приходит непосредственно от

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

несколько прокси-серверов. Ответ также является непосредственным, если

его достоверность только что была установлена непосредственно

первоначальным сервером.

- Точное время устаревания (explicit expiration time).

Время определенное первоначальным сервером и показывающее кэшу когда

объект больше не может быть возвращен клиенту без дополнительной

проверки достоверности.

- Эвристическое время устаревания (heuristic expiration time).

Время устаревания, назначенное кэшем, если не указано точное время

устаревания.

- Возраст (age).

Возраст ответа - время, прошедшее с момента отсылки, или успешной

проверки ответа первоначальным сервером.

- Время жизни (freshness lifetime).

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

- Свежий (fresh).

Ответ считается свежим, если его возраст еще не превысил время жизни.

- Просроченнный (stale).

Ответ считается просроченным, если его возраст превысил время жизни.

- Семантически прозрачный (semantically transparent).

Говорят, что кэш ведет себя "семантически прозрачным" образом в

отношении специфического ответа, когда использование кэша не влияет ни

на клиента запроса, ни на первоначальный сервер, но повышает

эффективность. Когда кэш семантически прозрачен, клиент получает точно

такой же ответ (за исключением промежуточных (hop-by-hop) заголовков),

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

а не кэш.

- Указатель достоверности (validator).

Элемент протокола (например, метка объекта или время последней

модификации (Last-Modified time)), который используется, чтобы

выяснить, является ли находящаяся в кэше копия эквивалентом объекта.

2. Общее описание.

Протокол HTTP - это протокол запросов/ответов. Клиент посылает по

соединению запрос серверу, содержащий: метод запроса, URI, версию

протокола, MIME-подобное сообщение, включающее модификаторы запроса,

клиентскую информацию и, возможно, тело запроса. Сервер отвечает строкой

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

выполнения или ошибки, MIME-подобным сообщением, содержащим информацию о

сервере, метаинформацию объекта и, возможно, тело объекта.

Большинство HTTP соединений, инициализируется агентом пользователя и

состоит из запроса, который нужно применить к ресурсу на некотором

первоначальном сервере. В самом простом случае, он может быть выполнен

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

первоначальным сервером.

Более сложная ситуация возникает, когда в цепочке запросов/ответов

присутствует один или несколько посредников. Существуют три основных

разновидности посредников: прокси-сервера, шлюзы, и туннели. Прокси-сервер

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

абсолютной форме, изменяет все сообщение или его часть и отсылает

измененный запрос серверу, идентифицированному URI. Шлюз - это принимающий

агент, действующий как бы на уровень выше некоторого другого сервера(ов) и

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

Туннель действует как реле (relay) между двумя соединениями не изменяя

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

посредника (например firewall), который не понимает содержание сообщений.

На рисунке показаны три посредника (A, B и C) между агентом

пользователя и первоначальным сервером. Запросы и ответы передаются через

четыре отдельных соединения. Это отличие важно, так как некоторые опции

HTTP соединения применимы только к соединению с ближайшим не туннельным

соседом, некоторые только к конечным точкам цепочки, а некоторые ко всем

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

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

получать запросы от других клиентов, а не только от A, и/или пересылать

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

запрос А.

Любая сторона соединения, которая действует не как туннель, может

использовать внутренний кэш для обработки запросов. Эффект кэша заключается

в том, что цепочка запросов/ответов сокращается, если один из участников в

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

показана цепочка, возникающая в том случае, когда B имеет кэшированую копию

раннего ответа O (полеченного через C) на запрос, и который не был

кэширован ни UA, ни A.

Не все ответы полезно кэшировать, а некоторые запросы могут содержать

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

поведением кэша.

Фактически, имеется широкое разнообразие архитектур и конфигураций

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

в World Wide Web; эти системы включают национальные иерархии прокси-кэшей,

которые сохраняют пропускную способность межокеанских каналов, системы,

которые распространяют по многим адресам содержимое кэша, организации,

которые распространяют подмножества кэшируемых данных на CD-ROM, и так

далее. HTTP системы используются в корпоративных интранет-сетях с

высокоскоростными линиями связи, и для доступа через PDA с маломощными

радиолиниями и неустойчивой связью. Цель HTTP/1.1 состоит в поддержании

широкого многообразия конфигураций, уже построенных при введении ранних

версий протокола, а также в удовлетворении потребностей разработчиков web

приложений, требующих все более высокой надежности.

HTTP соединение обычно происходит посредством TCP/IP соединений.

Заданный по умолчанию порт TCP - 80, но могут использоваться и другие порты

(например: 8080, 8081). HTTP также может быть реализован посредством любого

другого протокола Интернет, или других сетей. HTTP необходима только

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

протокол, который гарантирует надежную передачу данных; отображение

структуры запроса и ответа HTTP/1.1 на транспортные модули данных

рассматриваемого протокола - вопрос, не решается на уровне самого

протокола.

Большинство реализаций HTTP/1.0 использовало новое соединение для

каждого обмена запросом/ответом. В HTTP/1.1, установленное соединение может

использоваться для одного или нескольких обменов запросом/ответом, хотя

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

3. Параметры протокола.

3.1 Версия HTTP.

HTTP использует схему нумерации типа ".", для указания

версии протокола. Стратегия версификации протокола предназначена для того,

чтобы позволить отправителю указать формат сообщения и свои способности

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

посредством этой связи. При добавлении компонентов сообщения, которые не

воздействуют на процесс связи, или компонентов, которые добавляются только

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

протокол изменения добавляют возможности, которые не изменяют общий

алгоритм анализа сообщений, но расширяют семантику сообщения и

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

номер. Когда изменяется формат сообщения протокола увеличивается

номер.

Версия HTTP сообщения обозначается полем HTTP-version в первой строке

сообщения.

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Major и minor числа должны обрабатываться как отдельные целые числа и

что каждое может состоять более чем из одной цифры. Таким образом, HTTP/2.4

- более низкая версия, чем HTTP/2.13, которая в свою очередь ниже чем

HTTP/12.3. Нули должны игнорироваться получателями и не должны посылаться.

Приложения, посылающие сообщения запросов или ответов, которые

описывает спецификация HTTP/1.1, должны указывать версию HTTP (HTTP-

Страницы: 1, 2, 3, 4, 5, 6, 7