|
|||||||||
|
Музыка Каталог Программы Фотоальбомы Новости Игры Видео Обои Юмор Рефераты Клипы Фильмы |
|
Online video hd
Смотреть армянское видео
Официальный сайт toppromotion 24/7/365
Смотреть видео бесплатно
|
||||||||||||
|
||||||||||||
РефератыКоммуникации и связь (104)Протокол HTTP 1.1
Размер: 197.76 KB
Скачан: 85 Добавлен: 21.08.2005 
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ ЗАЧЕТНАЯ РАБОТА ПО ДИСЦИПЛИНЕ «Информационно-вычислительные сети» НА ТЕМУ «Протокол HTTP 1.1» |Работу выполнил: |Студент 5-го курса | МОСКВА 2002 г. 3.2.1 Общий синтаксис. 12 3.2.2 HTTP URL. 13 3.2.3 Сравнение URI. 13 3.3.1 Полная дата. 14 3.3.2 Разность секунд (delta seconds). 15 3.7.1 Канонизация и предопределенные значения типа text. 18 3.7.2 Типы Multipart. 19 5.1.1 Метод (Method). 25 5.1.2 URI запроса (Request-URI). 26 5.2 Ресурс, идентифицируемый запросом. 27 5.3 Поля заголовка запроса. 28 6.1.1 Код состояния и поясняющая фраза. 28 6.2 Поля заголовка ответа. 30 7.2.1 Тип. 31 7.2.2 Длина. 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.1.1 Безопасные методы. 36 9.1.2 Идемпотентные методы. 37 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.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 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.1 Устаревание, указанное сервером. 58 13.2.2 Эвристическое устаревание. 59 13.2.3 Вычисление возраста. 59 13.2.4 Вычисление устаревания. 61 13.2.5 Устранение противоречий в значениях устаревания. 62 13.2.6 Устранение противоречий между несколькими ответами. 62 1. Введение. Протокол передачи гипертекста (HTTP) - протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Первой версией Список 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 и 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. Шлюз - это принимающий агент, действующий как бы на уровень выше некоторого другого сервера(ов) и при необходимости транслирующий запросы в протокол основного сервера. На рисунке показаны три посредника (A, B и C) между агентом пользователя и первоначальным сервером. Запросы и ответы передаются через четыре отдельных соединения. Это отличие важно, так как некоторые опции Любая сторона соединения, которая действует не как туннель, может использовать внутренний кэш для обработки запросов. Эффект кэша заключается в том, что цепочка запросов/ответов сокращается, если один из участников в цепочке имеет кэшированный ответ, удовлетворяющий данному запросу. Далее показана цепочка, возникающая в том случае, когда B имеет кэшированую копию раннего ответа O (полеченного через C) на запрос, и который не был кэширован ни UA, ни A. Не все ответы полезно кэшировать, а некоторые запросы могут содержать модификаторы, которые указывают специальные требования, управляющие поведением кэша. Фактически, имеется широкое разнообразие архитектур и конфигураций кэшей и прокси-серверов, разрабатываемых в настоящее время или развернутых в World Wide Web; эти системы включают национальные иерархии прокси-кэшей, которые сохраняют пропускную способность межокеанских каналов, системы, которые распространяют по многим адресам содержимое кэша, организации, которые распространяют подмножества кэшируемых данных на CD-ROM, и так далее. HTTP системы используются в корпоративных интранет-сетях с высокоскоростными линиями связи, и для доступа через PDA с маломощными радиолиниями и неустойчивой связью. Цель HTTP/1.1 состоит в поддержании широкого многообразия конфигураций, уже построенных при введении ранних версий протокола, а также в удовлетворении потребностей разработчиков web приложений, требующих все более высокой надежности. HTTP соединение обычно происходит посредством TCP/IP соединений. Большинство реализаций 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/1.1, должны указывать версию HTTP (HTTP- version) "HTTP/1.1". Использование этого номера версии указывает, что посылающее приложение по крайней мере условно совместимо с этой спецификацией. HTTP версия приложения - это самая высокая HTTP версия, с которой приложение является по крайней мере условно совместимым ним. Приложения, реализующие прокси-сервера и шлюзы, должны обрабатывать протокольные сообщения различных версий. Начиная с момента, когда версия протокола указывает возможности отправителя, прокси-сервер/шлюз никогда не должен посылать сообщения, версия которых больше, чем HTTP версия отправителя; если получена более высокая версия запроса, то прокси- сервер/шлюз должен или понизить версию запроса, вернув сообщение об ошибке, или переключиться на туннельное поведение. У запросов, версия которых ниже, чем HTTP версия прокси-сервера/шлюза можно перед пересылкой увеличить версию; ответ прокси-сервера/шлюза на этот запрос должен иметь ту же самую major версию, что и запрос. Преобразование версий HTTP может включать модификацию полей заголовка, требуемых или запрещенных этими версиями. 3.2 Универсальный Идентификатор Ресурса (URI). URI известны под многими именами: WWW адреса, Универсальные 3.2.1 Общий синтаксис. URI в HTTP могут представляться в абсолютной форме (absolute URI) или относительно некоторого известного основного URI (relative URI), в зависимости от контекста их использования. Эти две формы различаются тем, что абсолютные 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 = Полная информация о синтаксисе и семантике URL содержится в RFC 1738 и Протокол HTTP не накладывает никаких ограничений на длины URI. Серверы должны обрабатывать URI любого ресурса, любой длинны, который они обслуживают, и им надлежит обрабатывать URI неограниченной длины, если они обслуживают сервера, основанные на методе GET, которые могут создавать такой URI. Серверу следует возвращать код состояния 414 (URI запроса слишком длинный, Request-URI Too Long), если URI длиннее, чем сервер в состоянии обработать. Серверы должны обращать внимание на URI, которые имеют длину более 255 байтов, потому что некоторые старые клиенты или прокси-сервера могут неправильно поддерживать эти длины. 3.2.2 HTTP URL. "Http" схема используется для доступа к сетевым ресурсам при помощи протокола HTTP. Этот раздел определяет схемо-определенный синтаксис и семантику для HTTP URL. http_URL = "http:" "//" host [ ":" port ] [ abs_path ] host = port = *DIGIT Если порт пуст или не задан - используется порт 80. Это означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса 3.2.3 Сравнение URI. При сравнении двух URI, чтобы решить соответствуют ли они друг другу или нет, клиенту следует использовать чувствительное к регистру пооктетное - Порт, который пуст или не указан, эквивалентен заданному по умолчанию порту для этого URI; - Сравнение имен хостов должно производиться без учета регистра; - Сравнение имен схем должно производиться без учета регистра; - Пустой abs_path эквивалентен "/". - Символы, отличные от тех, что находятся в "зарезервированных" ("reserved") и "опасных" ("unsafe") наборах эквивалентны их представлению как ""%" HEX HEX ". Например следующие три URI эквивалентны: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html h ttp://ABC.com:/%7esmith/home.html 3.3 Форматы даты/времени. 3.3.1 Полная дата. 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 Прис оздании приложений, желательно, чтобы оно умело воспринимать значения дат, которые, возможно, посланы не HTTP приложениями, а например Все без исключений форматы даты/времени в HTTP должны быть представлены в Greenwich Mean Time (GMT). В первых двух форматах данный факт указывается включением трехсимвольного сокращения "GMT" в качестве часового пояса. В asctime() формате это ДОЛЖНО подразумеваться при чтении. HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT" asctime-date = wkday SP date3 SP time SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT ; день месяц год (например 02 Jun 1982) date2 = 2DIGIT "-" month "-" 2DIGIT ; день-месяц-год (например 02-Jun- 82) date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) ; месяц день (например, Jun 2) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday" month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" Это требования формата даты/времени, которые применяются внутри потока протокола HTTP. Клиентам и серверам не требуется использовать эти форматы для представления пользователю, регистрации запросов и т.д. 3.3.2 Разность секунд (delta seconds). Некоторые поля HTTP заголовка позволяют указывать значения времени в виде целого числа секунд, представленного в десятичной форме, которые должны пройти с того момента, как сообщение было получено. delta-seconds = 1*DIGIT 3.4 Кодовые таблицы (character sets). HTTP использует то же самое определение термина "кодовая таблица", которое определено для MIME: Термин "кодовая таблица" используется, чтобы сослаться на метод, использующий одну или несколько таблиц для преобразования последовательности октетов в последовательность символов. Стоит отметить, что однозначное преобразование в обратном направлении не требуется, и что не все символы могут быть доступны в данной кодовой таблице, и что кодовая таблица может обеспечивать более чем одну последовательность октетов для представления специфических символов. Это определение допускает различные виды кодирования символов, от простых однотабличных отображений типа US- Кодовые таблицы 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 и Content-Encoding. Хотя значение описывает кодирование содержимого, но, что более важно - оно указывает, какой механизм декодирования потребуется для обратного процесса. Internet Assigned Numbers Authority (IANA) действует как реестр для значений лексем кодирования содержимого (content-coding). Первоначально реестр содержал следующие лексемы: gzip Формат кодирования, производящий сжатие файла программой "gzip" (GNU zip), описанный в RFC 1952. Это формат Lempel-Ziv кодирования (LZ77) с 32 разрядным CRC. compress Формат кодирования, производимый общей программой "compress" для сжатия UNIX файлов. Это формат адаптивного Lempel-Ziv-Welch кодирования (LZW). Конечно, использовать названия программ для идентификации форматов кодирования не желательно и может пересекаться с форматами, которые возникнут в последствии. Их использование объясняется исторической практикой. Для совместимости с предыдущими реализациями HTTP, приложения должны рассматривать "x-gzip" и "x-compress" как эквиваленты "gzip" и Новая лексема значения кодирования содержимого (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. Кодирования передачи - это аналоги значений Content-Transfer-Encoding Кодирование по кускам (chunked encoding) изменяет тело сообщения для передачи его последовательностью кусков, каждый из которых имеет собственный индикатор размера, сопровождаемым опциональным завершителем, содержащим поля заголовка объекта. Это позволяет динамически создаваемому содержимому передаваться вместе с информацией, необходимой получателю для проверки полноты получения сообщения. Chunked-Body = *chunk "0" CRLF footer CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF hex-no-zero = chunk-size = hex-no-zero *HEX chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ]) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) footer = *entity-header Кодирование по кускам (chunked encoding) оканчивается куском нулевого размера, следующим за завершителем, оканчивающимся пустой строкой. Цель завершителя состоит в эффективном методе обеспечения информации об объекте, который сгенерирован динамически; приложения не должны посылать в завершителе поля заголовка, которые явно не предназначены для использования в завершителе, такие как Content-MD5 или будущие расширения HTTP для цифровых подписей и других возможностей. Все HTTP/1.1 приложения должны быть в состоянии получать и декодировать кодирование передачи "по кускам" ("chunked" transfer coding), и должны игнорировать расширения кодирования передачи, которые они не понимают. Серверу, который получил тело объекта со значением кодирования передачи, которое он не понимает, следует возвратить ответ с кодом 501 (Не реализовано, Not Implemented) и разорвать соединение. Сервер не должен посылать поля кодирования передачи (transfer-coding) HTTP/1.0 клиентам. 3.7 Медиатипы (Media Types). HTTP использует МедиаТипы Интернета (Internet Media Types) в полях заголовка Content-Type и Accept для обеспечения открытой и расширяемой типизации данных и типов. media-type = type "/" subtype *( ";" parameter ) type = token subtype = token Параметры могут следовать за type/subtype в форме пар атрибут/значение parameter = attribute "=" value attribute = token value = token | quoted-string Тип, подтип, и имена атрибутов и параметров не чувствительны к регистру. Значения параметров могут быть чувствительными к регистру, но могут быть и не чувствительны, в зависимости от семантики имени параметра. Некоторые старые HTTP приложения не распознают параметры медиатипов. Значения медиатипов регистрируются Internet Assigned Number Authority 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 не должны заменять Если тело объекта кодируется при помощи Content-Encoding, то основные данные должны быть в определенной выше форме до кодирования. Параметр "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, и должны содержать разделительный параметр частью значения медиатипа. Тело сообщения В HTTP части тела (body-parts) типа multipart могут содержать поля заголовка, которые являются значащими в примнении к этой части. Поле заголовка Content-Location следует включать в часть тела (body-part) каждого включенного объекта, который может быть идентифицирован URL. Вообще говоря, HTTP агенту пользователя належит действовать так же как поступил бы MIME агент пользователя после получения типа multipart. Тип "multipart/form-data" был специально определен для передачи данных формы, подходящих для обработки методом запроса POST, что описано в RFC 3.8 Маркеры продуктов (Product Tokens). Маркеры продуктов используются, чтобы обеспечить коммуникационным приложениям возможность идентифицировать себя названием и версией программного обеспечения. Большинство полей, использующих маркеры продуктов также допускает перечисление подпрограмм, которые формируют значительную часть приложения, и которые перечисляются через пробел. В соответствии с соглашением, подпрограммы перечисляются в порядке их значения для идентификации приложения. product = token ["/" product-version] product-version = token Примеры: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4 Маркеры продуктов должны быть короткими и по сути - использование их для рекламы или другой несущественной информации однозначно запрещено. Хотя в лексеме product-version может встречаться любой символ, все же ее следует использовать только для идентификатора версии (то есть, последовательным версиям одной и той же программы надлежит иметь отличия только в части product-version лексемы product. 3.9 Величины качества (Quality Values). HTTP использует короткие числа "с плавающей точкой" для указания относительной важности ("веса") различных оговоренных параметров. Вес - это нормализованое вещественное число в диапазоне от 0 до 1, где 0 - минимальное, а 1 - максимальное значение. HTTP/1.1 приложения не должны генерировать более трех цифр после десятичной точки. Пользовательским конфигурациям этих значений следует также ограничиваться этим режимом. qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) "Величины качества" - не корректное название, так как эти значения просто представляют отношение снижения производительности к желательному качеству. 3.10 Метки языков (Language Tags). Метка языка идентифицирует естественный язык: разговорный, письменный, или другой используемый людьми для обмена информацмей с другими людьми. Синтаксис и запись меток языка в HTTP те же, что определены в RFC 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, If-Match, If-None-Match, и If-Range. Метка объекта состоит из непрозрачной строки, заключенной в кавычки (opaque quoted string), возможно предваренной индикатором слабости (weakness indicator). entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string "Сильная метка объекта" ("strong entity tag") может быть распространнена на два объекта ресурса, только тогда, когда они пооктетно эквивалентны. "Слабая метка объекта" ("weak entity tag"), обозначяемая префиксом Метка объекта должна быть уникальна среди всех версий всех объектов, связанных с конкретным ресурсом. Данное значение метки объекта может использоваться для объектов, полученных запросами различных URI без предположения эквивалентности этих объектов. 3.12 Единицы измерения диапазонов (Range Units). HTTP/1.1 позволяет клиенту запрашивать только часть объекта. HTTP/1.1 использует еденицы измерения диапазонов в полях заголовка Range и Content- 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 Сообщения запроса и ответа используют обобщенный формат сообщения RFC generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line В интересах ошибкоустойчивости, серверам следует игнорировать все пустые строки, полученные перед строкой запроса (Request-Line). Другими словами, если сервер читает поток протокола и в самом начале сообщения получает CRLF, то ему следует этот CRLF игнорировать. Некоторые ошибочные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Стоит вновь повторить, что это явно запрещено нормальной записью Бекуса-Наура. HTTP/1.1 клиент не должен добавлять дополнительные CRLF перед запросом и после него. 4.2 Заголовки сообщений. Поля заголовков HTTP, которые включают поля общих заголовков (general- header), заголовков запроса (request-header), заголовков ответа (response- header), и заголовков объекта (entity-header), имеют такой же обобщенный формат, как тот, что описан в разделе 3.1 RFC 822. Каждое поле заголовка состоит из имени поля, двоеточия (":") и значения поля. Имена полей не чувствительны к регистру. Значению поля может предшествовать любое число message-header = field-name ":" [ field-value ] CRLF field-name = token field-value = *( field-content | LWS ) field-content = Порядок, в котором получены поля заголовка с различными именами не имеет значения. Однако "хорошей практикой" является то, что сначала посылаются поля общих заголовков, затем поля заголовков запроса или заголовков ответа, и, наконец, поля заголовков объекта. Несколько полей заголовка с одиннаковыми именами могут присутствовать в сообщении тогда и только тогда, когда все значения полей, входящих в заголовок, определяют разделенный запятыми список [то есть #(value)]. 4.3 Тело cообщения. Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. message-body = entity-body | Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов. Правила, устанавливающие допустимость тела сообщения в сообщении, различаются для запросов и ответов. Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. ело сообщения (message-body) может быть добавлено в запрос только тогда, когда метод запроса допускает тело объекта (entity-body). Включать или не включать тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения (message- body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с информационными кодами состояния 1xx, кодом 204 (Нет содержимого, No 4.4 Длина сообщения. Когда тело сообщения (message-body) присутствует в сообщении, длина этого тела определяется одним из следующих методов (в порядке старшинства): 1. Любое сообщение ответа, которое не должно включать тело сообщения (message-body) (например ответы с кодами состояния 1xx, 204, 304 и все ответы на запрос HEAD) всегда завершается пустой строкой после полей заголовка, независимо от полей заголовка объекта (entity- header fields), представленных в сообщении. 2. Если поле заголовка Transfer-Encoding присутствует и указывает на применение кодирования передачи "chunked", то длина определяется кодированием по кускам (chunked encoding). 3. Если поле заголовка Content-Length присутствует, то его значение представляет длину тела сообщения (message-body) в байтах. 4. Если сообщение использует медиатип "multipart/byteranges", который саморазграничен, то он и определяет длину. Этот медиа тип не должен использоваться, если отправитель не знает, способен ли получатель его обработать; присутствие в запросе заголовка Range с несколькими спецификаторами диапазонов байтов (byte-range) подразумевает, что клиент может анализировать multipart/byteranges ответы. 5. Длина определяется закрытием соединения сервером. (Закрытие соединения не может использоваться для указания конца тела запроса, так как в этом случае у сервера не остается никакой возможности послать обратно ответ). Для совместимости с HTTP/1.0 приложениями HTTP/1.1 запросы, содержащие тело сообщения (message-body) должны включать допустимое поле заголовка Все HTTP/1.1 приложения, которые получают объекты, должны понимать кодирование передачи типа "chunked", таким образом разрешается использование данного механизма для таких сообщений, длина которых не может быть определена заранее. Сообщения не должны одновременно включать и поле заголовка Content- Если поле Content-Length присутствует в сообщении, которое допускает наличие тела сообщения (message-body), то значение поля должно точно соответствовать числу октетов в теле сообщения. HTTP/1.1 агенты пользователя должны информировать пользователя в случае получения и обнаружения недопустимой длины. 4.5 Общие поля заголовка. Имеется несколько полей заголовка, которые применяются как для сообщений запросов, так и для сообщений ответов, но которые не применяются к передаваемому объекту. Эти поля заголовка применяются только к передаваемому сообщению. general-header = Cache-Control | Connection | Date | Pragma | Transfer- Encoding | Upgrade | Via Имена общих полей заголовка (general-header fields) могут быть надежно расширены только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику общих полей заголовка (general-header fields), если все стороны соединения распознают их как общие поля заголовка. Нераспознанные поля заголовка обрабатываются как поля заголовка объекта (entity-header). 5. Запрос (Request). Сообщение запроса сервера клиентом содержит в первой строке: метод, который нужно применить к ресурсу, идентификатор ресурса и используемую версию протокола. Request = Request-Line *( general-header | request-header | entity- header ) CRLF [ message-body ] 5.1 Строка запроса (Request-Line). Строка запроса (Request-Line) начинается с лексемы метода, затем следует запрашиваемый URI (Request-URI), версия протокола и CRLF. Эти элементы разделяются SP. В строке запроса (Request-Line) не допустимы CR и Request-Line = Method SP Request-URI SP HTTP-Version CRLF 5.1.1 Метод (Method). Лексема метода указывает метод, который нужно применить к ресурсу, идентифицированному запрашиваемым URI (Request-URI). Метод чувствителен к регистру. Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | extension-method extension-method = token Список методов, применимых к ресурсу, может быть указан в поле заголовка Allow. Возврашаемый код состояния ответа всегда сообщает клиенту, допустим ли метод для ресурса в настоящее время, так как набор допустимых методов может изменяться динамически. Серверам следует возвратить код состояния 405 (Метод не допустим, Method Not Allowed), если метод известен серверу, но не применим для запрошенного ресурса, и 501 (Не реализовано, Методы GET и HEAD должны поддерживаться всеми универсальными (general- purpose) серверами. Остальные методы опциональны. 5.1.2 URI запроса (Request-URI). URI запроса (Request-URI) - это Единообразный Идентификатор Ресурса Request-URI = "*" | absoluteURI | abs_path Три опции для URI запроса (Request-URI) зависят от характера запроса. OPTIONS * HTTP/1.1 absoluteURI необходим, когда запрос производится через прокси-сервер. GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 Чтобы обеспечить переход к absoluteURI во всех запросах в будущих версиях HTTP, все HTTP/1.1 сервера должны принимать absoluteURI в запросах, хотя HTTP/1.1 клиенты будут генерировать их только в запросах к прокси- серверам. Наиболее общая форма Request-URI используется для идентификации ресурса на первоначальном сервере или шлюзе. В этом случае абсолютный путь GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org и далее остаток запроса. Абсолютный путь не может быть пустым; если оригинальный URI пуст, то он должен запрашиваться как "/" (корневой каталог сервера). Если прокси-сервер получает запрос без пути в Request-URI, и метод запроса допускает форму запроса "*", то последний прокси-сервер в цепочке запросов должен передать запрос, в котором Request-URI равен "*". Например запрос OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 был бы передан прокси-сервером в виде OPTIONS * HTTP/1.1 Host: www.ics.uci.edu:8001 после соединения с портом 8001 хоста "www.ics.uci.edu". Первоначальный сервер должен декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверам сдледует отвечать на недопустимые Request- В запросах, пересылаемых прокси-сервером, часть "abs_path" URI запроса Правило "ничто не перезаписывать" предохраняет прокси-сервера от изменения значения запроса, в котором первоначальный сервер неправильно использует не зарезервированные символы URL для своих целей. 5.2 Ресурс, идентифицируемый запросом. Первоначальные HTTP/1.1 сервера должны учитывать, что точный ресурс, идентифицируемый интернет-запросом определяется путем исследования запрашиваемого URI (Request-URI) и поля заголовка Host. Первоначальный сервер, который не различает ресурсы по запрошенному хосту (host), может игнорировать значение поля заголовка Host. Первоначальный сервер, который различает ресурсы на основании запрошенного хоста (host) (иногда называемые виртуальными хостами или 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 запроса, в котором отсутствует поле заголовка 5.3 Поля заголовка запроса. Поля заголовка запроса позволяют клиенту передать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса с семантикой, эквивалентной параметрам вызова методов в языках программирования. request-header = Accept | Accept-Charset | Accept-Encoding | Accept- Language | Authorization | From | Host | If-Modified-Since | If-Match | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | User-Agent Множество имен полей заголовка запроса (Request-header) может быть надежно расширено только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику полей заголовка запроса (Request-header), если все стороны соединения распознают их как поля заголовка запроса (Request-header). Нераспознанные поля заголовка обрабатываются как поля заголовка объекта (entity-header). 6 Ответ (Response). После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP ответа. Response = Status-Line *( general-header | response-header | entity- header ) CRLF [ message-body ] 6.1 Строка состояния (Status-Line). Первая строка ответа - это строка состояния (Status-Line). Она состоит из версии протокола (HTTP-Version), числового кода состояния (Status-Code) и поясняющей фразы (Reason-Phrase) разделенных символами SP. CR и LF не допустимы в Status-Line, за исключением конечной последовательности CRLF. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1 Код состояния и поясняющая фраза. Элемент код состояния (Status-Code) - это целочисленный трехразрядный код результата попытки понять и выполнить запрос. Эти коды полностью определены в разделе 10. Поясняющая фраза (Reason-Phrase) предназначена для короткого текстового описания кода состояния. Код состояния (Status-Code) предназначен для использования автоматами, а поясняющая фраза предназначена для живых пользователей. От клиента не требуется исследовать или отображать поясняющую фразу (Reason-Phrase). Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры: - 1xx: Информационные коды - запрос получен, продолжается обработка. - 2xx: Успешные коды - действие было успешно получено, понято и обработано. - 3xx: Коды перенаправления - для выполнения запроса должны быть предприняты дальнейшие действия. - 4xx: Коды ошибок клиента - запрос имеет плохой синтаксис или не может быть выполнен. - 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" ; Требуется установление ; подлинн |
|
|
|
Смотреть онлайн бесплатно
Онлайн видео бесплатно
