http

 

Исследование возможности передачи дополнительной информации с использованием стандартных протоколов в сети Internet.

Рассмотрение протокола HTTP.

 

Целью работы ставился поиск способов передачи дополнительной информации вне тела сообщения. Для этого был переведен и проанализирован документ RFC 1945, содержащий описание протокола передачи гипертекста HTTP версии 1.0 и разобрана структура различных типов запросов (get,post,head).

В ходе работы было выяснено следующее: поля HTTP заголовка включают поле общего заголовока, поле заголовка запроса, поле заголовка ответа и поле заголовка пакета. Каждое поле заголовка состоит из имени сопровождающегося двоеточием , символом пробела, и содержанием. Поля заголовка запроса позволяют клиенту передавать дополнительную информацию о сообщении запроса и о клиенте на сервер. Поля заголовка ответа позволяют серверу передавать дополнительную информацию об ответе, которая не может устанавливаться в статус-строке (Status Line). Эти поля заголовка дают информацию о сервере и о дальнейшем доступе к ресурсам идентифицируемым Запросом URI. Поля заголовка пакета ( Entity-Header) определяют дополнительную метаинформацию о содержании (Entity-Body) или о ресурсе к которому обращен запрос. Механизм расширения заголовка допускает дополнительные поля заголовка пакета (Entity-Header), которые должны быть определены без изменения протокола, но эти поля не распознаются получателем. Не распознанные поля заголовка должны игнорироваться получателем и пересылаться proxy.

Таким образом целесообразно передавать дополнительную информацию в виде поименованных строк, введенных в документ в качестве дополнительных полей заголовка. Эти поля не будут распознаваться ни агентом пользователя – браузером, ни сервером, на котором находится искомый ресурс.

Имена HTTP/1.0 могут озаглавливать различные строки, если каждая строка продолжается пробелом или символом горизонтальной табуляции после CRLF.Линейный пробел, включая свертку, имеет ту же семантику, что и SP.

LWS = [CRLF] 1*( SP | HT )

Поля заголовка могут расширяться многочисленными строками, предшествуя каждой дополнительной строке одним SP или HT, хотя это не рекомендуется.

HTTP-header = field-name ":" [field-value] CRLF

Field-name = token

Field-value = *(field-content | LWS)

Field-content = <the OCTETs making up the field-value

And consisting of either *TEXT or combinations of token, tspecials, and quoted-string>

Для просмотра введенных полей существует приложение HTTP Proxy-Spy 1.0, которое позволяет отслеживать трафик и фиксировать всю передаваемую информацию.

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

 

Протокол Передачи Гипертекста -- HTTP/1.0

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

Он обеспечивает легкую и быструю работу системы передачи, необходимую для распределенных информационных систем. НТТР - это общий объектно-ориентированный протокол, который может использоваться для выполнения различных задач. Например, для построения сервера доменных имен или системы управления распределенными объектами, реализуемого при помощи расширения метода запросов (команд). Особенной характеристикой HTTP является типизация представления данных, допускающая построение систем, не зависящих от передаваемых данных.

HTTP использовался глобальной всемирной сетью (World Wide Web) с 1990.

  1. Введение

1.1 Цель

 

В настоящее время функциональные возможности информационных систем расширяются. Простого поиска, удаленной коррекции и комментариев уже недостаточно. HTTP позволяет использовать открытый (open-ended) набор методов, который используется для указания цели запроса. Он строится по правилам, предусмотренным Универсальным Идентификатором Ресурса (Uniform Resource Identifier) (URI) как позиция (URL) или имя (URN), локализующее ресурс, к которому применяется метод. Сообщения передаются в формате подобном тому, который используется в Internet Mail и Multipurpose Internet Mail Extensions (MIME).

HTTP также используется в качестве основного протокола для связи пользователя через proxy-сервера/ ШЛЮЗЫ с Другими протоколами Интернет, такими как SMTP, NNTP, FTP, Gopher, и WAIS. Это позволяет упростить и унифицировать приложения пользователя, осуществляющие доступ к основным ресурсам сети.

1.2 Терминология

connection (соединение)-

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

message (сообщение)-

Основной модуль HTTP связи состоящий из структурируемой последовательности октетов (синтаксис которой задается в Главе 4), передающийся посредством соединения.

request (запрос)-

Сообщение HTTP запроса (Задается в Главе 5).

response (ответ)-

Сообщение HTTP ответа (Задается в Главе 6).

resource (ресурс)-

Сетевой объект данных или услуга, которые могут идентифицироваться URI.

Entity (пакет,объект)-

Конкретное представление или преобразование ресурса данных, или ответ сервисной службы, который может передаваться в качестве ответа на запрос. Пакет состоит из последовательности заголовков и наполнения (тела) данных.

client (клиент)-

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

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

Клиент, который вводит запрос. Это - броузеры, редакторы, пауки (роботы паутины) или другие инструментальные средства конечного пользователя.

server (сервер)-

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

origin server (сервер ресурса (начала))-

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

proxy-

Посредническая программа, которая выступает в качестве, как сервера по отношению к конечному пользователю, так и клиента по отношению к удаленному серверу. Запросы обслуживаются непосредственно или передаются на другие сервера. Proxy интерпретирует и, если необходимо, перезаписывает сообщение запроса перед его пересылкой. Proxy часто используются в качестве порталов через firewall и как вспомогательная программа по обработке запросов по протоколам не поддерживаемых пользовательскими приложениями.

gateway (шлюз)-

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

В отличие от proxy, шлюз получает запросы, как если бы он был сервером размещения

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

Шлюзы часто используются в качестве порталов через firewall и как трансляторы протокола при доступе к ресурсам системы, не поддерживающей протокол HTTP.

tunnel (туннель)-

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

cache (кэш)-

Кэш - локальный запас ответов и подсистема, управляющая их хранением, поиском, и удалением. Кэш загружает кэшируемые сообщения с целью уменьшения времени ответа на наиболее часто задаваемые запросы. Любой клиент или сервер, кроме туннеля, могут создавать кэш.

Любая рассматриваемая программа может быть как клиентом, так и сервером. Различие отмечается только в роли, выполняемой программой для конкретного соединения, а не в программных возможностях в общих чертах. Любой сервер может выступить в качестве сервера расположения ресурса, proxy, шлюза или туннеля в зависимости от каждого конкретного запроса.

1.3 Общее Функционирование

Протокол HTTP базируется на парадигме запрос/ответ. Клиент устанавливает соединение с сервером, посылая запрос на сервер в форме метода запроса, URI и версию протокола, сопровождая MIME сообщением, содержащим модификации запроса, информацию клиента, и, возможно, тело запроса. Сервер указывает в строке статуса версию протокола, сообщение об успешном завершении или код ошибки, сопровождая MIME сообщением, содержащим информацию сервера, метаинформацию и, возможно, тело.

Большинство HTTP соединений устанавливаются пользователями путем посылки запроса на сервер с целью поиска ресурса. В самом простом случае, это может выполняться через единственное соединение (v) между агентом пользователя (UA) и сервером расположения ресурса (O).

цепь запроса ------------------------>

UA -------------------v------------------- O

<----------------------- цепь ответа

Более сложная ситуация складывается в случае нескольких посредников в цепи запрос/ответ. Есть три общих формы посредника:proxy, gateway и tunnel. Proxy является экспедитором, получающим запросы о URI в абсолютной форме, перезаписывая всё или часть сообщения и пересылая переформатированный запрос на сервер идентифицирующий URI. Шлюз(gateway) выступает в качестве вышеуказанного некоторого другого сервера и, если необходимо, переводит запросы в основной протокол сервера. Туннель(tunnel) выступает в качестве реле между конечным пользователем и сервером расположения ресурса, не имеющим права изменять сообщения. Туннели используются, когда в соединении участвуют посредники (например, firewall), не изменяющие сообщения.

цепь запроса -------------------------------------->

UA -----v----- A -----v----- B -----v----- C -----v----- O

<------------------------------------- цепь ответа

Эта схема показывает трех посредников (A, B, и C) между агентом пользователя и сервером расположения ресурса. Запрос или ответ, которые проходят всю цепь, должны пройти каждый из четырех отдельных соединений. Хотя диаграмма линейная, каждый участник может подключаться в многопользовательском режиме. Например, B может получать запросы не только от клиента A, а пересылать запросы на другие серверы параллельно обработке запроса A.

Любой узел связи, который не выступает в качестве туннеля, может применить внутренний кэш для обработки запросов. Эффект от использования кэша в том, что цепь запрос/ответ сокращается если один из участников имеет кэш-ответ применительный к этому запросу. Следующая схема иллюстрирует результирующую цепочку, если B имеет кэш-копию более раннего ответа из O (через C) для запроса, который не кэширован UA или A.

цепь запроса ---------->

UA -----v----- A -----v----- B - - - - - - C - - - - - - O

<--------- цепь ответа

Не все ответы кэшируемы. Некоторые запросы могут содержать модификаторы, которые устанавливают специальные требования к кэшированию. Некоторые приложения HTTP/1.0 используют эвристику, чтобы описать ответ, но эти правила не нормализованы.

В Internet протокол HTTP относится к прикладному уровню модели TCP/IP. Встроенным портом TCP является 80, но также можно использовать и другие порты. Это не отстраняет HTTP от применения над другими протоколами Internet или в других сетях. HTTP только предполагает надежное перемещение сообщений; любой другой протокол, обеспечивающий такие гарантии, может быть использован для отображения структуры запроса и ответа HTTP/1.0 на основе данных протокола транспортного уровня.

За исключением экспериментальных приложений, текущая практика требует, чтобы соединение устанавливалось клиентом до каждого запроса, и закрывались сервером после посылки ответа. Как клиенты, так и серверы должны знать, что каждый может закрыть соединение преждевременно, из-за действий пользователя приводящих к задержке или к программной ошибке. В любом случае, закрытие соединения всегда завершает текущий запрос, независимо от статуса.

1.4 HTTP и MIME(Multipurpose Internet Mail Extension - универсальные почтовые расширения Internet)

HTTP/1.0 использует многие конструкции, определенные в MIME, как описано в RFC 1521. Контекст HTTP принимает во внимание другое использование Internet Media Types, что естественно обнаруживается в Internet mail.

2. Символьные Соглашения и Общая Грамматика

2.1 Расширение BNF

Все обозначения, используемые в этом документе, описаны в расширенной ФОРМЕ БЭКУСА-НАУРА (BNF). Расширение BNF включает следующие конструкции:

имя = определение

Имя правила является просто самим именем (без символов "<" и ">") и отделяется от своего определения символом "=". Пробел используется, чтобы указать определение правила, которое разделяет более чем одну строку. Определенные основные правила - в верхнем регистре, как, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и т.п..

Скобки используются в определениях всякий раз, когда их присутствие упрощает использование правила.

"литерал"

В кавычках заключается литерный текст. Если не установлено обратного, текст используется без учета регистра.

rule1 | rule2

Элементы, разделенные полосой ("|") - дают возможность выбора, например, "да | нет" означает да или нет.

(rule1 rule2)

Элементы, заключенные в круглых скобках рассматриваются как один элемент. Таким образом, "(a (b | c) d)" допускает символьные последовательности "a b d “ и "a c d".

* rule

Символ "*" предшествует элементу, указывающему на повтор. Полная форма - "<n>*<m>element" указывает от <n> до <m> элементов. Величины - 0 и бесконечность таковы, что "*(element)" допускает любое число, включая нуль;

"1*element" требует, по крайней мере, один; и "1*2element" допускает одно или два.

[rule]

Квадратные скобки предполагают дополнительные элементы; "[a b]" эквивалентно "*1(a b)".

N rule

Специфическое повторение: "<n>(element)" эквивалентно "<n>*<n>(element)"; это в точности случаи <n> (element). Таким образом, 2DIGIT - 2-цифровое число, и 3ALPHA - строка трех алфавитных символов.

#rule

Конструкция "#" определяется аналогично "*", для задания списков элементов. Полная форма - "<n>#<m>element" указывает от <n> до <m> элементов, каждый отделенный одной или более запятыми (",") и дополнительный линейный пробел (LWS). Это делает обычную форму списков очень легкой; например, "(* element LWS *( *LWS "," * element LWS ))" может быть показано как "1#element". Где бы эта конструкция ни использовалась, нулевые элементы допускаются, но не оказывают влияния на число элементов.

Например, конструкция как эта: "(элемент), , (элемент)" допускается, но считается только как два элемента. Следовательно, где требуется минимум один элемент, по крайней мере, один нулевой элемент должен присутствовать. Величины 0 и бесконечность таковы, что "#(element)" допускает любое число, включая нуль; "1#element" требует, по крайней мере, один; и "1#2element" допускает один или два.

; comment

Точка с запятой справа от текста правила отделяет комментарий. Это - простой способ включения полезных примечаний вместе со спецификацией.

implied *LWS

Грамматика, описанная этой спецификацией текстовая.

Кроме случаев, где оговаривается обратное, линейный пробел (LWS) может включаться между любыми двумя смежными словами (символьными или указывающими на строку), и между смежными признаками и разделителями (tspecials), не изменяя интерпретацию поля. По крайней мере, один разделитель (tspecials) должен существовать между любыми двумя признаками, поскольку они должны в противном случае быть проинтерпретированы как единственный признак. Тем не менее, приложения должны пытаться следовать "общей форме" создавая HTTP конструкции.

2.2 Основные Правила

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

OCTET = <any 8-bit sequence of data>

CHAR = <any US-ASCII character (octets 0 - 127)>

UPALPHA = <any US-ASCII uppercase letter "A".."Z">

LOALPHA = <any US-ASCII lowercase letter "a".."z">

ALPHA = UPALPHA | LOALPHA

DIGIT = <any US-ASCII digit "0".."9">

CTL = <any US-ASCII control character

(octets 0 - 31) and DEL (127)>

CR = <US-ASCII CR, carriage return (13)>

LF = <US-ASCII LF, linefeed (10)>

SP = <US-ASCII SP, space (32)>

HT = <US-ASCII HT, horizontal-tab (9)>

<"> = <US-ASCII double-quote mark (34)>

HTTP/1.0 определяет последовательность октета CR LF как маркер конца строки для всех элементов протокола кроме Entity-Body. Маркер конца строки в пределах Entity-Body определяется своим связанным типом носителя, как указано в Разделе 3.6.

CRLF = CR LF

Заголовки HTTP/1.0 могут складываться над различными строками, если каждая строка продолжается пробелом или символом горизонтальной табуляции после CRLF. Весь линейный пробел, включая свертку, имеет ту же семантику, что и SP.

LWS = [CRLF] 1*( SP | HT )

Тем не менее, свертка озаглавленных строк не может быть принята некоторыми приложениями, поэтому и не должна формироваться приложениями HTTP/1.0.

Правило TEXT используется только для описательного содержания области и величин, которые не должны интерпретироваться синтаксическим анализатором сообщения. Слова *TEXT могут также содержать октеты не только из набора символов US-ASCII.

TEXT = <any OCTET except CTLs,

but including LWS>

Получатели поля заголовка TEXT, содержащего октеты другого набора символов, нежели USASCII могут допустить, что они представляют ISO-8859-1 символы.

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

HEX = "A" | "B" | "C" | "D" | "E" | "F"

| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

Многие поля заголовков HTTP/1.0 состоят из слов разделенных LWS или специальными символами. Эти специальные символы должны быть в строковой константе, которая должна использоваться в пределах величины параметра.

word = token | quoted-string

token = 1*<any CHAR except CTLs or tspecials>

tspecials = "(" | ")" | "<" | ">" | "@"

| "," | ";" | ":" | "\" | <">

| "/" | "[" | "]" | "?" | "="

| "{" | "}" | SP | HT

Комментарии могут включаться в некоторые поля заголовка HTTP посредством окружения текста комментария круглыми скобками. Комментарии допускаются только в полях, содержащих "комментарий" как часть их определения величины поля.

Во всех других полях, круглые скобки считаются частью величины поля.

comment = "(" *( ctext | comment ) ")"

ctext = <any TEXT excluding "(" and ")">

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

quoted-string = ( <"> *(qdtext) <"> )

qdtext = <any CHAR except <"> and CTLs,

but including LWS>

Использование единственного символа обратной косой черты("\")в HTTP/1.0 не разрешается.

 

 

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

3.1 Версия HTTP

Для указания версии протокола HTTP использует исчисляемую схему "<major>.<minor>. Протокол позволяет отправителю указывать формат сообщения и его. Нельзя изменить номер версии так, чтобы поведение соединения осталось прежним или так, чтобы только добавилось расширяемое значение поля. Число <minor> увеличивается, когда изменения сделали в дополнительных характеристиках протокола, которые не изменяют общее содержание сообщения. Число <major> увеличивается, когда в пределах протокола изменен формат сообщения.

Версия HTTP сообщения указывается HTTP-Version в первой строке сообщения. Если версия протокола не определена, получатель должен предположить, что сообщение в простом формате HTTP/0.9.

HTTP-ВЕРСИЯ = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Имейте в виду, что числа major и minor должны быть рассмотрены как отдельные целые и, что каждое может быть увеличено больше чем на единицу.

Таким образом, HTTP/2.4 - более старая версия, чем HTTP/2.13, которая в свою очередь - старше, чем HTTP/12.3. Начальные Нули должны игнорироваться получателями.

серверы HTTP/1.0 должны:

· распознавать формат Request-Line для HTTP/0.9 и запрос HTTP/1.0;

· понимать любой правильный запрос в формате HTTP/0.9 или ответ HTTP/1.0;

· ставить в соответствие ответ запросу (ту же версию протокола, что использовал клиент);

клиенты HTTP/1.0 должны:

· распознавать формат Статуса-Строки для ответов HTTP/1.0;

· понимать любой правильный ответ в формат HTTP/0.9 или HTTP/1.0.

Proxy и межсетевые приложения должны аккуратно транспортировать запросы, которые получены в другом формате, нежели исконная HTTP версия. Proxy /шлюзы не должны посылать сообщения с указателем версии большим чем версия, с которой может работать клиент; если получен запрос высшей версии, proxy /шлюз должен или понизить версию запроса или указать ошибку. Запросы с версией ниже, чем исконный формат могут быть модернизированы до того как будут пересланы; proxy / gateway's ответы в этом запросе должны следовать требованиям сервера указанным выше.

3.2 Унифицированные Идентификаторы Ресурса (URI - Uniform Resource Identifiers)

URI известно под многими именами: адреса WWW, Универсальные Идентификаторы Документа, Универсальные Идентификаторы Ресурса, и, наконец, комбинация Однородных Локаторов Ресурса (URL) и Имена (URN).

3.2.1 Общий Синтаксис

URI в HTTP могут быть представлены в абсолютной форме или относительно некоторой известной базы 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 = <any OCTET excluding ALPHA, DIGIT,

reserved, extra, safe, and unsafe>

Для более подробной информации о синтаксисе и семантике URL, смотри RFC 1738 и RFC 808. BNF включает национальные символы, не допущенные по правилам URL, как определено RFC 1738, поскольку HTTP серверы не ограничились набором стандартных символов, допущенных для представления части rel_path адресов, HTTP proxy могут получить запросы о URI, не определенные в RFC 1738.

3.2.2 http URL (uniform recourse locator)

Схема "http" используется для нахождения сетевых ресурсов через HTTP протокол. Этот раздел определяет схему специфического синтаксиса и семантику для http URL.

http_URL = "http:" "//" host [ ":" port] [ abs_path ]

host = < имя host-а Internet или IP-адрес (в точечной десятичной форме), как определено Разделом 2.1 RFC 1123>

port = *ЦИФРА

Если порт пустой или не установлен, то по умолчанию принят порт 80. Определенный ресурс располагается на сервере, выделенном для TCP соединений к этому порту этого host-а, и запрос URI ресурса в виде abs_path. Если abs_path не представляет в URL, это должно быть дано как "/", когда использованное в качестве URI запроса (как описано в Разделе 5.1.2).

Примечание: Хотя HTTP протокол не зависит от транспортного протокола, http URL только идентифицирует ресурсы их TCP позицией, и таким образом не-TCP ресурсы должны идентифицироваться некоторой другой схемой URI.

3.3 Форматы Дата/Время

В приложениях HTTP/1.0 исторически сложилось три формата для представления даты/ времени:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036

Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

Первый формат предпочтителен как стандарт Internet и представляет подмножество фиксированной длины, которое определялось RFC 1123 (update RFC 822). Второй формат - общего использования, но базируется на устаревшем формате дат RFC 850.

клиенты HTTP/1.0 и серверы, которые выполняют грамматический разбор величины даты, должны принимать все три формата, хотя они никогда не должны генерировать третий (asctime) формат.

Все HTTP/1.0 отметки даты/ времени должны представлять в Универсальном Времени (UT), также известном как Greenwich Mean Time (ВРЕМЯ ПО ГРИНВИЧУ), без исключения.

Это указывается в первых двух форматах включением " 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

; day month year (e.g., 02 Jun 1982)

date2 = 2DIGIT "-" month "-" 2DIGIT

; day-month-year (e.g., 02-Jun-82)

date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))

; month day (e.g., 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.4 Набор Символов

HTTP ИСПОЛЬЗУЕТ то же определение "набора символов" что и MIME:

Термин "набор символов" используется для ссылки на таблицы преобразования последовательности октетов в последовательность символов. Имейте ввиду, что безусловное преобразование в другом направлении не рекомендуется. Это определение относится ко всем символьным кодировкам.

Примечание: Это использование "набора символов" обычно называют "символьная кодировка".

Набор символов HTTP идентифицируется без учета регистра. Все характеристики Набора Символов определяются IANA. Поскольку признаки не определены единственным образом для каждого набора символов, мы определяем здесь предпочтительные имена для наиболее часто используемых форм. Этот набор символов включает те зарегистрированные в RFC 1521 наборы символов US-ASCII и ISO-8859.

charset = "US-ASCII"

| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"

| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"

| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"

| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"

| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"

| token

 

Хотя HTTP допускает произвольный признак, который должен использоваться в качестве charset величины, любой признак, который предопределен в IANA, должен представлять определенный набор символов этого регистра. Приложения должны ограничивать их использование.

3.5 Кодирование

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

content-coding = "x-gzip" | "x-compress" | token

Примечание: Для будущей совместимости, приложения HTTP/1.0 должны рассматривать "gzip" и " compress", соответственно эквивалентным "x-gzip" и "x- compress ".

Все величины кодирования используются без учета регистра. HTTP/1.0 использует величины кодирования в Content-Encoding в области заголовка. Хотя величина описывает кодирование, более того важно - то, что она указывает требуемый механизм декодирования. Имейте ввиду, что одиночная программа может быть декодирована различными способами. Две величины определяются следующей спецификацией:

x-gzip

Кодирующий формат производился файловой программой сжатия "gzip" (GNU zip) разработанное Jean-loup Gailly. Этот формат является естественно Lempel-Ziv кодированием (LZ77) с 32 битовым CRC.

x- compress

Кодирующий формат производился файловой программой сжатия " compress ". Этот формат является адаптивным Lempel-Ziv-Welch кодированием (LZW).

Примечание: Использование программных имен для идентификации кодировки форматов не желательно. Их использование здесь отражает историческую практику, а не правила хорошего тона.

3.6 Тип Носителя

HTTP использует Internet Media Types в заголовке Content-Type ( Раздел 10.5).

media-type = type "/" subtype *( ";" parameter )

type = token

subtype = token

Параметры могут следовать за типом/подтипом в форме пары атрибут/величина.

parameter = attribute "=" value

attribute = token

value = token | quoted-string

 

Тип, подтип, и имена атрибута параметра - без учета регистра. Параметр учитывает либо не учитывает регистр, в зависимости от семантики имени параметра. LWS не должно генерироваться между типом и подтипом, ни между атрибутом и величиной. При получении типа носителя с неопределенным параметром агент пользователя должен рассматривать тип носителя как неопределенный параметр, а величину непредставимой.

Некоторые более старые HTTP приложения не распознают параметры типа носителя.

приложения HTTP/1.0 должны только использовать параметры типа носителя, когда они необходимы, чтобы определить содержание сообщения.

 

3.6.1 Канонические формы и установки по умолчанию.

Типы носителей Internet регистрируются в канонической форме. В общих чертах, тело передаваемого объекта должно быть представлено в соответствующей канонической форме до своей передачи. Если тело закодировано, то основные данные должны быть представлены в канонической форме до кодировки.

Подтипы носителя типа " text " используют в канонической форме CRLF как текстовое прерывание строки. Тем не менее, HTTP допускает транспорт текстового носителя только с CR или LF прерывания, когда использовано в пределах тела объекта.

Кроме того, если текст представлен в наборе символов, который не использует октеты 13 и 10 для CR и LF соответственно, HTTP допускает использование независимо от того какие последовательности октетов определяются этим набором символов, чтобы представить эквивалент CR и LF для прерываний строки. Эта гибкость относительно строки прерываний, относится только к текстовому носителю тела объекта; чистое CR или LF не должно заменяться CRLF в пределах любого из HTTP управляющих структур (как, например, области заголовка).

Параметр "charset" используется с некоторыми типом носителя, чтобы определить набор символов данных. Когда никакой явный charset параметр не предусматривается передатчиком, подтипы носителя типа "текст" определяются, чтобы установить по умолчанию charset величины "ISO-8859-1", когда получено через HTTP. Данные в наборе символов кроме "ISO-8859-1" или подмножества должны помечаться с соответствующей charset величиной для того, чтобы последовательно интерпретироваться получателем.

Примечание: Многие из HTTP серверов обеспечивают использование данных, с величиной charset отличной от "ISO-8859-1" без соответствующей отметки. Эта ситуация уменьшает способность к взаимодействию и не рекомендуется. Для того, чтобы компенсировать это, некоторые HTTP агенты пользователя предоставляют опцию конфигурации позволяющую пользователю изменять встроенную интерпретацию набора типа носителя символов, когда никакой charset параметр не дан.

3.6.2 Тип Multipart

MIME предусматривает для типа "multipart" – инкапсуляцию различных объектов в пределах единственного сообщения. Тип multipart зарегистрированный IANA не имеет специального значения для HTTP/1.0, хотя агенты пользователя вероятно должны понимать каждый тип , чтобы правильно интерпретировать цель каждой части тела. Агент пользователя HTTP должен также реагировать на обработку типа multipart как и агент пользователя MIME.

Все объекты типа multipart имеют общий синтаксис и должны включать параметр границы как часть величины типа носителя. Тело сообщения - сам элемент протокола и должен использовать только CRLF, для представления прерывания строки между частями тела. Части Multipart тела могут содержать области HTTP заголовка, которые являются значимыми в этой части.

3.7 Признаки Продукта

Признаки Продукта используются, чтобы дать возможность передаваемым приложениям идентифицировать самих себя через простой признак продукта, с дополнительным слешем и обозначением версии. Большинство областей используют признаки продукта, также допускают промежуточные результаты, которые формируют значимую часть приложения, разделяясь пробелом. Соглашением, продукты указываются в порядке их значения для идентификации приложения.

product = token ["/" product-version]

product-version = token

Примеры:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

Признаки Продукта должны быть короткими и по существу, -- использование их для рекламы или другая несущественная информация запрещена. Хотя любой символ может появиться в версии продукта, этот признак должен только использоваться для идентификатора версии (то есть, последующие версии того же самого продукта должны только отличаться в части версия продукта значения продукта).

4. HTTP СООБЩЕНИЕ

4.1 Тип Сообщения

HTTP Сообщения состоят из запросов от клиента к серверу и ответов сервера клиенту.

HTTP-message = Simple-Request ; HTTP/0.9 messages

| Simple-Response

| Full-Request ; HTTP/1.0 messages

| Full-Response

Полный-Запрос и Полный Ответ используют общий формат сообщений RFC 822 для передачи пакетов. Оба сообщения могут включить дополнительные области заголовка (также известные как "заголовки") и тело пакета. Тело пакета выделяется из заголовков пустой.

Full-Request = Request-Line ;

*( General-Header ;

| Request-Header ;

| Entity-Header ) ;

CRLF

[ Entity-Body ] ;

Full-Response = Status-Line ;

*( General-Header ;

| Response-Header ;

| Entity-Header ) ;

CRLF

[ Entity-Body ] ;

 

Простой - Запрос и Простой-Ответ не допускают использование любой информации заголовка и ограничены единственным методом запроса (GET).

Simple-Request = "GET" SP Request-URI CRLF

Simple-Response = [ Entity-Body ]

Использование формата Простого Запроса нежелательно из-за того, что он предохраняет сервер от идентификации типа носителя возвращенного пакета.

4.2 Заголовки Сообщения

Поля HTTP заголовка, которые включают поля: Общий заголовок, Заголовок запроса, Заголовок ответа и Заголовок пакета, следуют общему формату, описанному в RFC 822. Каждое поле заголовка состоит из имени сопровождающегося двоеточием (":"), символом пробела (SP), и величиной области.

Области Заголовка могут расширяться многочисленными строками, предшествуя каждой дополнительной строке одним SP или HT, хотя это не рекомендуется.

HTTP-header = field-name ":" [field-value] CRLF

Field-name = token

Field-value = *(field-content | LWS)

Field-content = <the OCTETs making up the field-value

And consisting of either *TEXT or combinations of token, tspecials, and quoted-string>

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

Тем не менее, принято посылать поля Общего Заголовка сначала, затем Заголовок запроса или Заголовок ответа до поля Заголовка пакета.

 

4.3 Общие Поля Заголовка

Есть несколько полей заголовка, которые имеют общую применимость, как для запроса, так и для сообщений ответа, но, который не относится к передаваемому пакету. Эти заголовки прилагаются только в передаваемом сообщении.

General-Header = Date

Имя общего поля заголовка может быть расширено только в комбинации с изменением в версии протокола. Тем не менее, новые или экспериментальные поля заголовка могут иметь семантику общих областей заголовка, если все посредники соединения распознают их как общие поля заголовка.

 

5. Запрос

Запрос клиента к серверу включает, в пределах первой строки этого сообщения, методы, которые должны относиться к ресурсу, идентификатору ресурса, и версии протокола. Для обратной совместимости с более ограниченным протоколом HTTP/0.9, есть два правильных формата для HTTP запроса:

Request = Simple-Request | Full-Request

Simple-Request = "GET" SP Request-URI CRLF

Full-Request = Request-Line

*( General-Header

| Request-Header

| Entity-Header )

CRLF

[ Entity-Body ]

Если сервер HTTP/1.0 получает Простой запрос, то он должен указать HTTP/0.9 Простой ответ. Клиент HTTP/1.0 способный получить Полный ответ не должен никогда сгенерировать Простой запрос.

5.1 Строка запроса

Строка запроса начинается с признака метода, сопровождающимся запросом URI и версией протокола, и окончанием с CRLF. Элементы разделяются символами SP. CR или LF не допускаются за исключением конечной последовательности CRLF.

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

 

Имейте ввиду, что различие между Простым запросом и строкой запроса Полного запроса - присутствие HTTP-Версии области и доступность методов кроме GET.

5.1.1 Метод

Признак Метода указывает метод, который должен выполняться в ресурсе идентифицируемом запросом URI.

Method = "GET"

| "HEAD"

| "POST"

| extension-method

extension-method = token

Список методов приемлемых к специфическим ресурсам может измениться динамически; клиент извещается через код возврата об ответе если метод не доступен ресурсу. Серверы должны возвращать статус кода 501 (не осуществленное) если метод неопределен или не осуществлен.

5.1.2 Запрос URI

Запрос URI является Однородным Идентификатором Ресурса и идентифицирует ресурс к которому относится запрос.

Request-URI = absoluteURI | abs_path

Две опции запроса URI зависят от природы запроса.

absoluteURI форма допускается, когда запрос относится к proxy. Proxy пересылает запрос и возвращает ответ. Если запрос - GET или HEAD и предшествующий ответ кэширован, proxy может использовать кэш-сообщение. Имейте ввиду, что proxy может переслать запрос на другой proxy или непосредственно на сервер определенном как absoluteURI. Избегая циклов запросов, proxy должен распознать все имена сервера, включая любые псевдонимы, локальные изменения, и числовой адрес IP. Пример Строки запроса должен быть:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0

Наиболее общая форма запроса URI, идентифицирующая ресурс на сервере или шлюзе. В этом случае, передается только абсолютный маршрут URI.

Запрос URI передается как закодированная строка, где некоторых символов могут избегать, используя "% HEX HEX" кодировку определенную в RFC 1738. Сервер начала должен декодировать запрос URI для того, чтобы правильно интерпретировать просьбу.

5.2 Поля Заголовка Запроса

Поля заголовка запроса позволяют клиенту передавать дополнительную информацию о просьбе и о клиенте на сервер.Эти области выступают в качестве модификаторов запроса, с семантикой эквивалентной параметрам в методе языка программирования (процедуры) вызова.

Request-Header = Authorization

| From

| If-Modified-Since

| Referer

| User-Agent

Имя поля Заголовка Запроса может быть расширено только в комбинации с изменением в версии протокола. Тем не менее, новые или экспериментальные области заголовка могут иметь семантику областей заголовка запроса если все посредники соединения распознают их как области заголовка запроса. Неопределенные поля заголовка рассматривают как поля Заголовка пакета.

6. Ответ

После получения и интерпретации сообщения запроса сервер отвечает в форме HTTP сообщения ответа.

Full-Response = Status-Line ;

*( General-Header ;

| Response-Header ;

| Entity-Header ) ;

CRLF

[ Entity-Body ] ;

Простой-Ответ должен только быть послан в ответ на HTTP/0.9 Простой-Запрос или если сервер поддерживает только более ограниченный протокол HTTP/0.9. Если клиент посылает HTTP/1.0 Полный-Запрос и получает ответ, который не начинается со Статус строки, то должен считать что ответ является Простым ответом и выполнять грамматический разбор соответственно этому. Имейте. ввиду, что Простой-Ответ состоит только из тела пакета и сервер после его отправления закрывает соединение.

6.1 Статус Строка

Первая строка сообщения Полного Ответа является Статус строкой, состоящая из версии протокола сопровождающейся числовым кодом статуса и связанной текстовой фразой, с каждым элементом, разделенным символами SP. CR или LF не допускаются за исключением конечной последовательности CRLF.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Статус строка всегда начинается с версии протокола и кодом статуса

"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

(например,, "HTTP/1.0 200 "), присутствие этого выражения достаточно, чтобы различить Полный-Ответ от Простого ответа.

Хотя формат Простого Ответа допускает нахождение такого выражения в начале тела пакета, и таким образом вызывать неправильное понимание сообщения, если он давался в ответ на Полный-Запрос, большинство серверов HTTP/0.9 ограничены ответами типа "текста/html" и, следовательно, не должны никогда сгенерировать такой ответ.

6.1.1 Код Статуса и Reason Phrase

Статус кодовый элемент является 3-х значным кодом результата целого типа попытки понять и удовлетворить запрос. Reason Phrase описывает Статус-Код. Статус-Код предназначается для использования автоматами и Reason Phrase. Клиент не требует отображать Reason Phrase.

Первая цифра Статуса-Кода определяет класс ответа. Последние две цифры не играют роли в классификации. Есть 5 значений для первой цифры:

o 1xx: Информационный - Не используется, но зарезервировано для будущего использования

o 2xx: Успех - действие успешно завершено.

o 3xx: Переадресация - Дальнейшее действие должно завершить запрос

o 4xx: Ошибка Клиента - запрос содержит не правильный синтаксис или не может быть выполнено

o 5xx: Ошибка Сервера - сервер отказывается выполнять, очевидно, правильный запрос

Значения кодов статуса, определенные для HTTP/1.0, и примеры набора соответствующих reason phrases, представлены ниже. Reason phrases приведенные ниже только рекомендуются. Они могут заменяться локальными эквивалентами, не влияя на протокол.

Status-Code = "200" ; OK

| "201" ; Created

| "202" ; Accepted

| "204" ; No Content

| "301" ; Moved Permanently

| "302" ; Moved Temporarily

| "304" ; Not Modified

| "400" ; Bad Request

| "401" ; Unauthorized

| "403" ; Forbidden

| "404" ; Not Found

| "500" ; Internal Server Error

| "501" ; Not Implemented

| "502" ; Bad Gateway

| "503" ; Service Unavailable

| extension-code

extension-code = 3DIGIT

Reason-Phrase = *<TEXT, excluding CR, LF>

HTTP коды статуса расширяются, но вышеуказанные коды являются единственными распознаваемыми на практике. HTTP приложения не требуют распознавания значений всех зарегистрированных кодов статуса, хотя понимание желательно. Тем не менее, приложения должны понять класс любого кода статуса, как указано первой цифрой, и рассматривать любой не узнанный ответ как, являющийся эквивалентным коду статуса x00 этого класса, с исключением, которое не узнанный ответ не должен быть кэширован. Например, если не узнанный код статуса 431 получен клиентом, он может благополучно допустить, что был неправильно распознан запрос, и рассматривает ответ, как если бы он получил код статуса 400. В таких случаях, агенты пользователя должны представлять пользователю пакет, возвращаемый с ответом, с информацией, которая объяснит необычный статус.

6.2 Поля Заголовка Ответа

Поля заголовка ответа позволяют серверу передавать дополнительную информацию об ответе, которая не может устанавливаться в Status Line. Эти области заголовка дают информацию о сервере и о дальнейшем доступе к ресурсам идентифицируемым Запросом URI.

Response-Header = Location

| Server

| WWW-Authenticate

Имена полей Ответа Заголовка могут быть расширены надежно только в комбинации с изменением в версии протокола. Тем не менее, новые или экспериментальные области заголовка могут иметь семантику полей заголовка ответа если все участники соединения распознают их как поля заголовка ответа. Нераспознанные поля заголовка трактуются как поля Entity-Header.

7. Пакет

Сообщения полного запроса и полного ответа могут передавать пакеты в пределах некоторых запросов и ответов. Пакет состоит из полей Entity-Header и (обычно) Entity-Body. В этом разделе, как отправитель, так и получатель ссылаются на клиента или на сервер, в зависимости от того, кто посылает и кто принимает пакет.

7.1 Поля Entity-Header (Заголовок Пакета)

Поля Entity-Header определяют дополнительную метаинформацию о Entity-Body или о ресурсе к которому обращен запрос.

Entity-Header = Allow

| Content-Encoding

| Content-Length

| Content-Type

| Expires

| Last-Modified

| extension-header

extension-header = HTTP-header

Механизм расширения заголовка допускает дополнительные поля Entity-Header, которые должны быть определенными без изменения протокола, но эти области не могут быть распознаны получателем. Не узнанные области заголовка должны игнорироваться получателем и пересылаться proxy.

7.2 Entity Body (Тело пакета)

Тело пакета (если имеется) посланное с HTTP запросом или ответом - в формате определенном полем Entity-Header.

Entity-Body = *OCTET

Тело пакета включается в сообщение запроса только когда метод запроса вызывает его. Присутствие тела пакета в запросе отмечается включением поля Content-Length в заголовке сообщения запроса. Запросы HTTP/1.0, содержащие тело пакета должны включить правильно оформленное поле заголовка Content-Length.

Для сообщений ответа, включено или нет тело пакета в сообщение зависит как от метода запроса так и от кода ответа. Все ответы на метод запроса HEAD не должны включать тело, даже если присутствие полей заголовка пакета может разрешить им. Все 1xx (информационный), 204 (без содержания), и 304 (не модифицированное) ответы не должны включать тело. Все другие ответы должны включить тело пакета или поле заголовка Content-Length определенные нулем (0).

7.2.1 Тип

Когда Entity-Body включается в сообщение, тип данных этого тела определяется через области заголовка Content-Type и Content-Encoding. Они определяют двух уровневую модель:

entity-body := Content-Encoding( Content-Type( data ) )

Content-Type определяет тип носителя основных данных. Content-Type может использоваться, чтобы указать любое дополнительное сжатие. Не существует способа кодировки по умолчанию.

Любое сообщение HTTP/1.0, содержащее entity body должно включить поле заголовка Content-Type определяющее тип носителя поля этого тела. Если тип носителя не указан в заголовке Content-Type, тогда получатель может попытаться догадаться о типе носителя посредством проверки своего содержания и/или расширение имени URL использованный, чтобы идентифицировать ресурс. Если тип носителя остается неизвестным, получатель должен обращаться с ним как с типом "application/octet-stream".

7.2.2 Длина

Когда Entity-Body включается в сообщение, длина этого тела может быть определена одним из двух способов. Если заголовок Content-Length присутствует, то там указана величина длины Entity-Body в байтах. В противном случае, длина тела определяется закрытием соединения сервером.

Закрытие соединения не может использоваться, чтобы указать конец тела запроса, поскольку он не оставил никакой возможности для сервера, чтобы возвратить ответ. Следовательно, запросы HTTP/1.0 содержащие entity body должны включить правильный заголовок Content-Length. Если запрос содержит entity body и Content-Length не определяется, и сервер не распознает или не может вычислить длину из других областей, то сервер должен послать 400 (плохой запрос).

8. Определения Метода

Комплект общих методов для HTTP/1.0 определен ниже. Хотя этот набор может расширяться, дополнительные методы не могут распространять ту же семантику для отдельно расширенных клиентов и серверов.

8.1 GET

Метод GET означает, извлекать независимо от того какая информация (в форме entity) идентифицируется Запросом-URI. Если Запрос-URI имеет отношение к процессу произведение данных, это - изготовленные данные, которые должны быть возвращены как entity в ответе.

Семантика метода GET изменяется на "условный GET" если сообщение запроса включает If-Modified-Since области заголовка. Условный метод GET запрашивает определенный ресурс только если он модифицирован после даты указанной в заголовке If-Modified-Since. Условный метод GET собирается уменьшать сетевое использование допуская кэширование entities, которые должны освежаться не требуя многочисленных запросов или передачу необязательных данных.

8.2 Заголовок

Метод HEAD идентичен, методу GET за исключением того что сервер не должен возвращать Entity-Body в ответ. Метаинформация содержащаяся в HTTP заголовках в ответ на Главный запрос была бы идентичной на информации посланной в ответ на запрос GET. Этот метод может использоваться для получения метаинформации о ресурсе идентифицирующем Запросом-URI не передавая само Предприятие-Тело. Этот метод часто используется для испытания связей гипертекста для достоверности, доступности, и последней модификации.

Нет "условного HEAD " запроса аналогичного на условному GET. Если If-Modified-Since область заголовка включилась с HEAD запросом, это должно быть проигнорировано.

8.3 POST

Метод POST используется, чтобы запросить, некоторый сервер принять расположения объекта как новый подчиненный ресурс идентифицированный Запросом-URI на Запросе-Строке. POST разрабатывается, чтобы позволить однородному методу покрывать следующие функции:

- Комментарий существующих ресурсов;

- Отправление почтового сообщения;

- Обеспечение блока данных как например, результат подачи формы в процессе обработки данных;

- Расширение базы данных через функционирование добавления.

Фактическая функция представленная методом POST определяется сервером и обычно подчинена Запросу-URI. Объявленный объект является подчиненным URI так же, что файл является подчиненным директории, содержащей его, статья новостей является подчиненной newsgroup на который она ссылается, или запись является подчиненной в базы данных.

Успешный POST не требует, чтобы предприятие создавалось как ресурс на сервере начала или сделан доступным для будущей ссылки. Это, действие, выполненное методом POST не могло закончиться ресурсом, который может идентифицироваться URI. В этом случае или 200 (ok) или 204 (без содержания) - соответствующий статус ответа, в зависимости от ответа включает объект, который описывает результат.

Если ресурс создан на сервере начала, ответ должен быть 201 (созданный) и содержать объект (типа " text /html"), которое описывает статус запроса и имеет отношение к новому ресурсу.

Приложения не должны кэшировать ответы на запрос POST.

9. Определения Кода Статуса

Каждый Статус-Код описанный ниже, включая описание метода, который может следовать и любую метаинформацию, требующуюся в ответ.

9.1 Информационный 1xx

Этот класс кода статуса указывает временный ответ, состоящий только из Статуса-Строки и дополнительных заголовков, и завершающийся пустой строкой. HTTP/1.0 не определяет любые коды статуса 1xx и они не - правильный ответ в просьбе HTTP/1.0.

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

9.2 Успешный 2xx

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

GET объект соответствующий запрошенному ресурсу послан в ответ;

HEAD ответ должен содержать только информацию заголовка;

POST объект, описывающий или, содержащий результат действия.

 

9.3 Переадресация 3xx

Этот класс кода статуса указывает, что дальнейшее действие должно быть выполнено агентом пользователя для удовлетворения запроса. Необходимое действие может выполняться агентом пользователя без взаимодействия с пользователем тогда и только тогда метод использованный на последующем запросе - GET или HEAD. Агент пользователя не должен никогда автоматически переназначить запрос более чем 5 раз, с таких переадресаций обычно указывают бесконечный цикл.

 

9.4 Ошибка Клиента 4xx

Класс 4xx кода статуса предназначается для случаев, в которых клиент допустил ошибку. Если клиент не завершил запрос, когда код 4xx получен, это должно немедленно прекратить посылку данных на сервере. Кроме ответа на HEAD запрос, сервер должен включить объект, содержащий объяснение ситуации ошибки, и независимо от этого - временное или постоянное условие. Эти коды статуса применительны к любому методу запроса.

Примечание: Если клиент посылает данные, реализации сервера на TCP должны быть осторожными, чтобы гарантировать, что клиент подтверждает получение пакета(s), содержащего ответ до закрытия входного соединения. Если клиент продолжает посылать данные на сервер после закрытия, контроллер сервера пошлет пакет сброса клиенту, который может стереть непризнанные входные буфера клиента прежде, чем они смогли бы быть прочитаны и проинтерпретированы HTTP приложением.

9.5 Ошибка Сервера 5xx

Статус Ответа кодирует начало с цифрой "5" указывать случаи, в которых сервер заметил свою ошибку или не способен выполнить запрос. Если клиент не завершил запрос, когда код 5xx получен, он должно немедленно прекратить посылку данных на сервер. Кроме ответа на HEAD запрос, сервер должен включить объект, содержащий объяснение ситуации ошибки, и независимо от этого - временное или постоянное условие.

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

10. Определения Области Заголовка

Этот раздел определяет синтаксис и семантику всех обычно использующихся областей заголовка HTTP/1.0. Для general и entity полей заголовка, как отправитель так и получатель ссылаются или на клиента или на сервер, в зависимости от того кто посылает и кто принимает сообщение.

10.1 Allow

Область Allow entity -заголовка включает комплект методов поддерживающихся ресурсом идентифицирующим Запросом-URI. Цель этой области проинформировать получателя о правильных методах, связываемых с ресурсом. К области заголовка Allow нет доступа при запросе, использующем метод POST, и таким образом должна игнорироваться если она получена как часть объекта POST.

Allow = "Allow" ":" 1#method

Пример использования:

Allow: GET, HEAD

Proxy не должно модифицировать область заголовка Allow даже если он не понимает всех методов.

Область заголовка Allow не указывает, какие методы осуществляются сервером.

10.2 Разрешение

Агент пользователя, который хочет аутентифицировать себя с server--

usually, не после получения ответа 401, -может сделать это, включая Authorization области request-header запроса. Величина области Authorization состоит из верительных грамот, содержащих информацию об аутентификации агента пользователя для области ресурса.

Authorization = "Authorization" ":" credentials

10.3 Content-Encoding

Поле Content-Encoding использовано в качестве модификатора media-type . Эта величина указывает какое дополнительное кодирование относиться к ресурсу, и таким образом какой механизм декодирования должено быть применен. Content-Encoding изначально используется для сжатия документа без потери данных.

Content-Encoding = "Content-Encoding" ":" content-coding

10.4 Content-Length

 

Content-Length указывает размер Entity-Body, в десятичном числе октетов, посланных получателю или, в случае метода HEAD, размер Entity-Body, которое было бы послано в случае метода GET.

Content-Length = "Content-Length" ":" 1*DIGIT

Пример

Content-Length: 3495

Приложения должны использовать эту область, чтобы указать размер Entity-Body, которое должно передаваться, независимо от типа носителя объекта.

.

10.5 Content-Type

Content-Type указывает тип носителя Entity-Body посланного получателю или, в случае метода HEAD, тип носителя, который был бы послан запросом GET.

Content-Type = "Content-Type" ":" media-type

 

10.6 Date

Date области general-header представляет дату и время когда сообщение было создано.

Date = "Date" ":" HTTP-date

Пример

Date: Tue, 15 Nov 1994 08:12:31 GMT

Если сообщение получено через прямое соединение с агентом пользователя (в случае запросов) или сервером начала (в случае ответов), то дата может приниматьсяв качестве текущей даты на принимаемой стороне.

10.7 Expires

Expires показывает дату после которой объект считается устаревшим. Это позволяет поставщикам информации предлагать динамичный ресурс, или дату после какого информация не может больше быть в силе. Приложения не должны кэшировать этот объект за данной датой. Присутствие области Expires не гарантирует существование данного ресурса по истечении времени. Тем не менее, поставщики информации, которые знают, что ресурс изменится должны включить заголовок Expires с этой датой. Формат - абсолютная дата и время.

Expires = "Expires" ":" HTTP-date

Пример своего использования

Expires: Thu, 01 Dec 1994 16:00:00 GMT

 

10.8 From

Область From должна содержать электронный адрес почты Internet для пользователя, который управляет запросом агента пользователя. Адрес должен быть машинно-пригодным, как определено почтовым ящиком в RFC 822 :

From = "From" ":" mailbox

Пример:

From: webmaster@w3.org

Эта область заголовка может использоваться для регистрации целей и как средства для установления источника неправильных или нежелательных запросов. Это не должно быть использовано в качестве небезопасной формы защиты доступа. Интерпретация этой области - в том, что запрос выполняется от имени человека, который несет ответственность за выполняемый метод. В конкретном, агенты робота должны включить этот заголовок так, что человек ответственный за прогон робота может обращаться.

10.9 If-Modified-Since

If-Modified-Since область используется с методом GET, чтобы сделать его условным: если запрошенный ресурс не модифицирован с тех пор как время определялось в этой области, копия ресурса не возвратится из сервера; взамен, 304 (не модифицированное) ответ возвратится без любого Entity-Body.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Пример области:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

 

 

10.10 Last-Modified

Last-Modified область указывает дату и время когда ресурс последний раз был модифицирован. Точная семантика этой области определяются с точки зрения получателя: если получатель имеет копию этого ресурса, который является более старым, чем дата данная область Last-Modified то копия считается устаревшей.

Last-Modified = "Last-Modified" ":" HTTP-date

Пример своего использования

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Точное значение этой области заголовка зависит от реализации передатчика и природы исходного ресурса. Для файлов, это может быть именно файловой системой Last-Modified время. Для объектов с динамически включенными частями, это может быть наиболее последнее Last-Modified время для своих компонентов. Для шлюзов базы данных, это может быть последней коррекцией отметки времени записи. Для виртуальных объектов, это может быть в последний раз изменое внутреннее состояние.

 

10.11 Location

Область Location определяет точную позицию ресурса, который идентифицировался Запросом-URI. Для ответов 3xx, позиция должна указать сервер URL для автоматической переадресации в ресурсе. Только один абсолютный URL допущен.

Location = "Location" ":" absoluteURI

Пример

Location: http://www.w3.org/hypertext/WWW/NewLocation.html

10.12 Pragma

Pragma используется, чтобы включить директивы implementation-specific, которые могут относиться к любому получателю вдоль цепи запроса/ответа. Все директивы Pragma определяют дополнительное поведение с точки протокола; тем не менее, некоторые системы могут потребовать, чтобы поведение было соответствующим директивам.

Pragma = "Pragma" ":" 1#pragma-directive

pragma-directive = "no-cache" | extension-pragma

extension-pragma = token [ "=" word ]

 

10.13 Referer

Referer позволяет клиенту определять, для пользы сервера, адрес (URI) ресурса от которого Запрос-URI был получен. Это позволяет серверу генерировать списки обратных-связей в ресурсах для регистрации оптимизирующих кэширование, и т.п.. Он также допускает устаревший или не типовые связи, которые должны прослеживаться для эксплуатации. Область Referer не должна быть послана если Запрос-URI получался из источника, который не имеет собственный URI, как например, ввод с клавиатуры пользователя.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Пример:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

 

10.14 Server

Server содержит информацию о программном обеспечении использованном сервером начала, чтобы отвечать на запрос. Область может содержать многочисленные признаки продукта и комментарии опознавая сервер и любые значимые промежуточные результаты. Соглашением, признаки продукта указываются в порядке их значения для установления приложения.

Server = "Server" ":" 1*( product | comment )

Пример:

Server: CERN/3.0 libwww/2.17

Если ответ пересылается через proxy, приложение proxy не должно добавить свои данные к списку продукта.

 

10.15 User-Agent

User-Agent содержит информацию об агенте пользователя, порождающем запрос. Это - для статистических целей, трассировки нарушений протокола, и автоматизирующих опознавание агентов пользователя для подгонки ответов, чтобы избегать конкретных ограничений агента пользователя. Хотя не требуется, чтобы агенты пользователя включали эту область в запросы. Область может содержать многочисленные признаки продукта и комментарии опознавая агента и любых промежуточных результатов, которые формируют значимую часть агента пользователя. Соглашением, признаки продукта указываются в порядке их значения для установления приложения.

User-Agent = "User-Agent" ":" 1*( product | comment )

Пример:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

 

10.16 WWW-Authenticate

WWW-Authenticate должна включаться в 401 (несанкционированные) сообщения ответа. Величина области состоит по крайней мере из одного вызова, который указывает схему аутентификации и параметры применительные к Запросу-URI.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

 

 

11. Аутентификация Доступа

HTTP обеспечивает простую аутентификацию механизма вызова, которая может использоваться сервером, чтобы вызвать запрос клиента ,и клиентом, чтобы обеспечить информацию аутентификации. Он использует расширяемый, признак без учета регистра, чтобы идентифицировать схему аутентификации, сопровождающуюся списком пар свойств, которые несут параметры необходимые для достижения аутентификации через эту схему.

auth-scheme = token

auth-param = token "=" quoted-string

401 (Несанкционированное) сообщение ответа используется сервером начала, чтобы вызвать разрешение агента пользователя. Этот ответ должен включить WWW-Authenticate содержащий, по крайней мере, один вызов применительный к запрошенному ресурсу.

challenge = auth-scheme 1*SP realm *( "," auth-param )

realm = "realm" "=" realm-value

realm-value = quoted-string

Атрибут области (без учета регистра) необходим для всех схем аутентификации, которые выпускают вызов. Величина области (с учетом регистра) в комбинации с каноническим корнем URL сервера, являющегося доступным, определяет пространство защиты. Эти области допускают защищенные ресурсы в сервер, которые должны быть библиотечными в комплект пробелов защиты, каждые со своей собственной схемой аутентификации и/или базой данных разрешения. Величина области является строкой, обычно назначенной сервером начала, которая может иметь дополнительную семантику специфическую на схеме аутентификации.

Протокол HTTP не ограничивает приложения в этом простом механизме аутентификации доступа. Могут использоваться дополнительные механизмы, например, шифрование на уровне транспорта или через инкапсуляцию сообщения, и с дополнительными областями заголовка, определяющими информацию аутентификации. Тем не менее, эти дополнительные механизмы не определяются этой спецификацией.

Proxies должны быть полностью прозрачными относительно аутентификации агента пользователя. Они должны переслать WWW-Authenticate и заголовки Authorization нетронутые, и не должны кэшировать ответ на запросе, содержащем Разрешение. HTTP/1.0 не предоставляет средства для клиента удостоверяться с proxy.

11.1 Основная Схема Аутентификации

Схема аутентификации базируется на модели, которую агент пользователя должен удостоверить себя с пользовательским ID и паролем для каждой области. Величина области должна считаться непрозрачную строку, которая может только сравниваться для равенства с другими областями в этом сервере.

Сервер уполномочит запрос, только если он может подтвердить правильность пользовательского ID и пароля для пространства защиты Запроса-URI.

Нет дополнительных параметров аутентификации.

По Получению несанкционированного запроса о URI в пределах пространства защиты сервер должен указать вызов подобно следующему:

WWW-Authenticate: Basic realm="WallyWorld"

где "WallyWorld" - строка, назначенная сервером, чтобы идентифицировать пространство защиты Запроса-URI.

Для того, чтобы получать разрешение, клиент посылает пользовательский ID и пароль, разделенные единственным двоеточием (":"):

basic-credentials = "Basic" SP basic-cookie

basic-cookie = <base64 [5] encoding of userid-password,

except not limited to 76 char/line>

userid-password = [ token ] ":" *TEXT

 

12. Соображения Безопасности

Этот раздел предназначен, чтобы проинформировать прикладных разработчиков, поставщиков информации, и пользователей об ограничениях безопасности в HTTP/1.0 как указано этим документом. Дискуссия не включает окончательные решения в проблемы обнаруженные, хотя она делает некоторые предложения для уменьшения риска.

12.1 Аутентификация Клиентов

Основная схема аутентификации не является безопасным методом аутентификации пользователя, он не предохраняет Entity-Body от атаки на физическом уровне. HTTP/1.0 не предлагает дополнительные схемы аутентификации и механизмы шифрования.

12.2 Безопасные Методы

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

В конкретном соглашение установлено, что GET и HEAD методы не должны никогда иметь значение действия сбора кроме поиска. Эти методы должны считаться безопасными. Это позволяет агентам пользователя представлять другие методы, например, POST, на специальном пути, так, что пользователь сделан осведомленным о то, что возможно ненадежное действие.

Естественно, не возможно гарантировать, что сервер не генерирует побочные эффекты в результате выполнения запроса GET; фактически, некоторые динамические ресурсы рассматривают эту характеристику

12.3 Злоупотребление Информацией Протокола Сервера

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