Протокол передачи гипертекстаСеменов Ю.А. (ГНЦ ИТЭФ), book.itep.ru Протокол передачи гипертекста HTTP является протоколом прикладного уровня для распределенных мультимедийных информационных систем. Это объектно-ориентированный протокол, пригодный для решения многих задач, таких как создание серверов имен, распределенных объектно-ориентированных управляющих систем и др.. Структура HTTP позволяет создавать системы, независящие от передаваемой информации. Протокол HTTP использован при построении глобальной информационной системы World-Wide Web (начиная с 1990). Первые версии, такие как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли являются последними. Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений сходен с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions). HTTP используется также в качестве базового протокола для коммуникации пользовательских агентов с прокси-серверами и другими системами Интернет, в том числе и использующие протоколы SMTP, NNTP, FTP, Gopher и Wais. Последнее обстоятельство способствует интегрированию различных служб Интернет. Ниже описаны базовые понятия и термины протокола HTTP. Прокси Промежуточная программа, которая выполняет функции, как сервера, так и клиента. Такая программа предназначена для обслуживания запросов так, как если бы это делал первичный сервер. Запросы обслуживаются внутри или переадресуются другим серверам. Туннель Промежуточная программа, которая работает как ретранслятор между двумя объектами. Туннель закрывается, когда обе стороны, соединенные им прерывают сессию. Туннель может быть активирован с помощью HTTP-запроса. Время пригодности объекта (expiration time) Время, при котором исходный сервер требует, чтобы объект не посылался более кэшем без перепроверки пригодности. Эвристическое значение времени жизни (heuristic expiration time) Время пригодности, присваиваемое объекту в кэше, если это время не задано явно. Возраст Возраст отклика - время с момента его посылки или проверки его пригодности исходным сервером. Время жизни (freshness lifetime) Продолжительность времени с момента генерации отклика до истечения его пригодности. Свежий Отклик считается свежим, если его возраст не превысил времени его пригодности. Устаревший Отклик считается устаревшим, когда его возраст превысил время жизни. Семантическая прозрачность Кэш по отношению к конкретному отклику функционирует в 'семантически прозрачном' режиме, когда его использование не имеет последствий ни для исходного сервера, ни для запрашивающего клиента. Когда кэш семантически прозрачен, клиент получает в точности тот же отклик (за исключением транспортных заголовков), какой он бы получил при непосредственном обращении к исходному серверу. Валидатор Протокольный элемент (например, метка объекта или время last-modified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта. Метод Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.). Взаимодействие клиента, кэша и исходного сервера в протоколе HTTP Кэш может находиться в ЭВМ клиента или агента пользователя, но может размещаться на соседнем континенте. Число прокси между клиентом и исходным сервером может варьироваться и ограничивается сверху только здравым смыслом. Структура ресурса и объекта Протокол HTTP представляет собой протокол запросов-откликов. Клиент посылает запрос серверу в форме, определяющей метод, URI и версию протокола. В конце запроса следует MIME-подобное сообщение, содержащее модификаторы, информацию о клиенте и, возможно, другие данные. Сервер откликается, посылая статусную строку, которая включает в себя версию протокола, код результата (успех/неудача) и MIME-подобное сообщение, в котором содержатся данные о сервере и метаинформация. Большинство HTTP-обменов инициируются пользователем и состоят из запросов ресурсов, имеющихся на определенном сервере. В простейшем случае такой запрос может быть реализован путем соединения пользовательского агента (UA) и базового сервера. Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартные формы посредников: прокси, туннель и внешний порт (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) представляет собой приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка-точка и не производит каких-либо видоизменений сообщений. Туннель используется тогда, когда нужно пройти через какую-то систему (например, Firewall) в условиях, когда эта система не понимает (не анализирует) содержимое сообщений. Запрос --------------------------------------> Рис. 4.5.6.1.3 UA - агент пользователя На рисунке показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A, и переадресовывать запросы к другим серверам кроме C. Любой участник обмена, который не используется в качестве туннеля, может воспользоваться кэшем для запоминания запросов. Буфер может сократить длину цепочки в том случае, если у одного из участников процесса имеется в буфере отклик для конкретного запроса, что может, кроме прочего, заметно снизить требования к пропускной способности канала. Не все запросы могут записываться в кэш, некоторые из них могут содержать модификаторы работы с кэшем. В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии прокси-серверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, распространяющие фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-системы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости. Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает использования HTTP поверх любого другого протокола в Интернет, или других сетей. HTTP предполагает надежное соединение; применим любой протокол, который может гарантировать корректную доставку сообщений. В HTTP/1.0, большинство приложений используют новое соединение для каждого обмена запрос/отклик. В HTTP/1.1, соединение может быть использовано для одного или более обменов запрос/отклик, хотя соединение может быть разорвано по самым разным причинам. | |
1 | Соглашения по нотации и общая грамматика |
1.1 | Расширенные BNF |
1.2 | Основные правила |
2 | Параметры протокола |
2.1 | Версия HTTP |
2.2 | Универсальные идентификаторы ресурсов (URI) |
2.2.1 | Общий синтаксис |
2.2.2 | HTTP URL |
2.2.3 | Сравнение URI |
2.3 | Форматы даты/времени |
2.3.1 | Полная дата |
2.3.2 | Интервалы времени в секундах |
2.4 | Наборы символов |
2.5 | Кодировки содержимого |
2.6 | Транспортное кодирование |
2.7 | Типы среды |
2.7.1 | Канонизация и текст по умолчанию |
2.7.2 | Составные типы |
2.8 | Лексемы (token) продукта |
2.9 | Значения качества (Quality values) |
2.10 | Языковые метки |
2.11 | Метки объектов |
2.12 | Структурные единицы |
3 | http сообщение |
3.1 | Типы сообщений |
3.2 | Заголовки сообщений |
3.3 | Тело сообщения |
3.4 | Длина сообщения |
3.5 | Общие поля заголовка |
4 | Запрос |
4.1 | Строка запроса |
4.1.1 | Метод |
4.1.2 | URI запроса |
4.2 | Ресурс, идентифицируемый запросом |
4.3 | Поля заголовка запроса |
5 | Отклик |
5.1 | Статусная строка |
5.1.1 | Статусный код и словесный комментарий |
5.2 | Поля заголовка отклика |
6 | Объект (Entity) |
6.1 | Поля заголовка объекта |
6.2 | Тело объекта |
6.2.1 | Тип |
6.2.2 | Длина |
7 | Соединения |
7.1 | Постоянные соединения |
7.1.1 | Цель |
7.1.2 | Общие процедуры |
7.1.2.1 | Согласование |
7.1.2.2 | Буферизация |
7.1.3 | Прокси-серверы |
7.1.4 | Практические соображения |
7.2 | Требования к передаче сообщений |
8 | Метод определений |
8.1 | Безопасные и idempotent методы |
8.1.1 | Безопасные методы |
8.1.2 | Подобные методы |
8.2 | Опции |
8.3 | Метод GET |
8.4 | Метод HEAD |
8.5 | Метод POST |
8.6 | Метод PUT |
8.7 | Метод DELETE |
8.8 | Метод TRACE |
9 | Определения статусных кодов |
9.1 | 1xx Info |
9.1.1 | 100 Continue |
9.1.2 | 101 Switching Protocols |
9.2 | 2xx Successful |
9.2.1 | 200 OK |
9.2.2 | 201 Created |
9.2.3 | 202 Accepted |
9.2.4 | 203 Non-Authoritative Information |
9.2.5 | 204 No Content |
9.2.6 | 205 Reset Content |
9.2.7 | 206 Partial Content |
9.3 | 3xx Redirection |
9.3.1 | 300 Multiple Choices |
9.3.2 | 301 Moved Permanently |
9.3.3 | 302 Moved Temporarily |
9.3.4 | 303 See Other |
9.3.5 | 304 Not Modified |
9.3.6 | 305 Use Proxy |
9.4 | 4xx Client Error |
9.4.1 | 400 Bad Request |
9.4.2 | 401 Unauthorized |
9.4.3 | 402 Payment Required |
9.4.4 | 403 Forbidden |
9.4.5 | 404 Not Found |
9.4.6 | 405 Method Not Allowed |
9.4.7 | 406 Not Acceptable |
9.4.8 | 407 Proxy Authentication Required |
9.4.9 | 408 Request Timeout |
9.4.10 | 409 Conflict |
9.4.11 | 410 Gone |
9.4.12 | 411 Length Required |
9.4.13 | 412 Precondition Failed |
9.4.14 | 413 Request Entity Too Large |
9.4.15 | 414 Request-URI Too Long |
9.4.16 | 415 Unsupported Media Type |
9.5 | 5xx Server Error |
9.5.1 | 500 Internal Server Error |
9.5.2 | 501 Not Implemented |
9.5.3 | 502 Bad Gateway |
9.5.4 | 503 Service Unavailable |
9.5.5 | 504 Gateway Timeout |
9.5.6 | 505 HTTP Version Not Supported |
10 | Идентификация доступа |
10.1 | Базовая схема идентификации (Authentication) |
10.2 | Краткое изложение схемы авторизации |
11 | Согласование содержимого |
11.1 | Согласование, управляемое сервером |
11.2 | Согласование, управляемое агентом (Agent-driven Negotiation) |
11.3 | Прозрачное согласование (Transparent Negotiation) |
12 | Кэширование в HTTP |
12.1 | Корректность кэша |
12.2 | Предупреждения |
12.3 | Механизмы управления кэшем |
12.4 | Прямые предупреждения агента пользователя |
12.5 | Исключения для правил и предупреждений |
12.6 | Работа под управлением клиента |
12.7 | Модель истечения срока |
12.7.1 | Определение срока годности под управлением сервера |
12.7.2 | Эвристический контроль пригодности |
12.7.3 | Вычисление возраста |
12.7.4 | Вычисление времени жизни (Expiration) |
12.7.5 | Устранение неопределенности значений времени жизни |
12.7.6 | Неопределенность из-за множественных откликов |
12.8 | Модель проверки пригодности |
12.8.1 | Даты последней модификации |
12.8.2 | Валидаторы кэша для меток объектов (Entity Tag Cache Validators) |
12.8.3 | Слабые и сильные валидаторы |
12.8.4 | Правила того, когда использовать метки объекта и даты последней |
12.8.5 | Условия пригодности |
12.9 | Кэшируемость отклика |
12.10 | Формирование откликов кэшей |
12.10.1 | Заголовки End-to-end (точка-точка) и Hop-by-hop (шаг-за-шагом) |
12.10.2 | Немодифицируемые заголовки |
12.10.3 | Комбинирование заголовков |
12.10.4 | Комбинирование байтовых фрагментов |
12.11 | Кэширование согласованных откликов |
12.12 | Кэши коллективного и индивидуального использования |
12.13 | Ошибки и поведение кэша при неполном отклике |
12.14 | Побочные эффекты методов GET и HEAD |
12.15 | Несоответствие после актуализации или стирания |
12.16 | Обязательная пропись (Write-Through Mandatory) |
12.17 | Замещения в кэше |
12.18 | Списки предыстории |
13 | Определения полей заголовка |
13 | Определения полей заголовка |
13.1 | Поле Accept |
13.2 | Поле Accept-Charset |
13.3 | Поле Accept-Encoding |
13.4 | Поле Accept-Language |
13.5 | Поле Accept-Ranges |
13.6 | Поле Age |
13.7 | Поле Allow |
13.8 | Авторизация |
13.9 | Поле Cache-Control |
13.9.1 | Что допускает кэширование? |
13.9.2 | Что может быть записано в память кэша? |
13.9.3 | Модификации базового механизма контроля времени жизни |
13.9.4 | Управление перепроверкой пригодности и перезагрузкой |
13.9.5 | Директива No-Transform |
13.9.6 | Расширения управления кэшем |
13.10 | Соединение |
13.11 | Content-Base |
13.12 | Кодирование содержимого |
13.13 | Язык содержимого |
13.14 | Длина содержимого |
13.15 | Поле Content-Location |
13.16 | Content-MD5 |
13.17 | Фрагмент содержимого |
13.18 | Тип содержимого |
13.19 | Дата |
13.20 | Поле ETag |
13.21 | Поле Expires |
13.22 | Поле From |
13.23 | Поле Host |
13.24 | Поле If-Modified-Sinc |
13.25 | Поле If-Match |
13.26 | Поле If-None-Match |
13.27 | Заголовок If-Range |
13.28 | Поле If-Unmodified-Since |
13.29 | Поле Last-Modified |
13.30 | Поле Location |
13.31 | Поле Max-Forwards |
13.32 | Поле Pragma |
13.33 | Поле Proxy-Authenticate |
13.34 | Поле Proxy-Authorization |
13.35 | Поле Public |
13.36 | Фрагмент |
13.36.1 | Фрагменты байт |
13.36.2 | Запросы получения фрагментов |
13.37 | Поле Referer |
13.38 | Поле Retry-After |
13.39 | Поле Server |
13.40 | Поле Transfer-Encoding (Транспортное кодирование) |
13.41 | Заголовок Upgrade (Актуализация) |
13.42 | Поле User-Agent (Агент пользователя) |
13.43 | Поле Vary |
13.44 | Поле Via |
13.45 | Поле Warning (Предупреждение) |
13.46 | Поле WWW-Authenticate |
14 | Соображения безопасности |
14.1 | Аутентификация клиентов |
14.2 | Предложение выбора схемы идентификации |
14.3 | Злоупотребление служебными (Log) записями сервера |
14.4 | Передача конфиденциальной информации |
14.5 | Атаки, основанные на именах файлов и проходов |
14.6 | Персональная информация |
14.7 | Аспекты конфиденциальности, связанные с заголовками Accept |
14.8 | Фальсификация DNS |
14.9 | Заголовки Location и мистификация |
15 | Библиография |
16 | Приложения |
16.1 | Интерентовский тип среды "message/http" |
16.2 | Тип среды Интернет "multipart/byteranges" |
16.3 | Толерантные приложения |
16.4 | Различие между объектами HTTP и MIME |
16.4.1 | Преобразование к канонической форме |
16.4.2 | Преобразование форматов даты |
16.4.3 | Введение кодирования содержимого |
16.4.4 | No Content-Transfer-Encoding |
16.4.5 | Поля заголовка в многофрагментных телах |
16.4.6 | Введение транспортного кодирования |
16.4.7 | MIME-Version |
16.5 | Изменения по отношению HTTP/1.0 |
16.5.1 | Изменения с целью упрощения распределенных WWW-сервером и экономии IP адресов |
16.6 | Дополнительные функции |
16.6.1 | Дополнительные методы запросов |
16.6.1.1 | Метод PATCH |
16.6.1.2 | Метод LINK |
16.6.1.3 | Метод UNLINK |
16.6.2 | Определения дополнительных полей заголовка |
16.6.2.1 | Поле Alternates |
16.6.2.2 | Поле Content-Version |
16.6.2.3 | Поле Derived-From |
16.6.2.4 | Поле Link |
16.6.2.5 | Поле URI |
16.7 | Совместимость с предыдущими версиями |
16.7.1 | Совместимость с постоянными соединениями HTTP/1.0 |
16.7.1.1 | Заголовок Keep-Alive |