Быстрый поиск

Реферат: Протокол HTTP 1.1

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

Более сложная ситуация возникает, когда в цепочке запросов/ответов присутствует один или несколько посредников. Существуют три основных разновидности посредников: прокси-сервера, шлюзы, и туннели. Прокси-сервер является агентом-посредником, который получает запросы на некоторый URI в абсолютной форме, изменяет все сообщение или его часть и отсылает измененный запрос серверу, идентифицированному URI. Шлюз - это принимающий агент, действующий как бы на уровень выше некоторого другого сервера(ов) и при необходимости транслирующий запросы в протокол основного сервера. Туннель действует как реле (relay) между двумя соединениями не изменяя сообщений; туннели используются, когда связь нужно производить через посредника (например firewall), который не понимает содержание сообщений.

Подпись:

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

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

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

Подпись:

Фактически, имеется широкое разнообразие архитектур и конфигураций кэшей и прокси-серверов, разрабатываемых в настоящее время или развернутых в World Wide Web; эти системы включают национальные иерархии прокси-кэшей, которые сохраняют пропускную способность межокеанских каналов, системы, которые распространяют по многим адресам содержимое кэша, организации, которые распространяют подмножества кэшируемых данных на CD-ROM, и так далее. HTTP системы используются в корпоративных интранет-сетях с высокоскоростными линиями связи, и для доступа через PDA с маломощными радиолиниями и неустойчивой связью. Цель HTTP/1.1 состоит в поддержании широкого многообразия конфигураций, уже построенных при введении ранних версий протокола, а также в удовлетворении потребностей разработчиков web приложений, требующих все более высокой надежности.

HTTP соединение обычно происходит посредством TCP/IP соединений. Заданный по умолчанию порт TCP - 80, но могут использоваться и другие порты (например: 8080, 8081). HTTP также может быть реализован посредством любого другого протокола Интернет, или других сетей. HTTP необходима только надежная передача данных, следовательно может использоваться любой протокол, который гарантирует надежную передачу данных; отображение структуры запроса и ответа HTTP/1.1 на транспортные модули данных рассматриваемого протокола - вопрос, не решается на уровне самого протокола.

Большинство реализаций HTTP/1.0 использовало новое соединение для каждого обмена запросом/ответом. В HTTP/1.1, установленное соединение может использоваться для одного или нескольких обменов запросом/ответом, хотя соединение может быть закрыто по ряду причин.

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

3.1 Версия HTTP.

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

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

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

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

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

HTTP версия приложения - это самая высокая HTTP версия, с которой приложение является по крайней мере условно совместимым ним.

Приложения, реализующие прокси-сервера и шлюзы, должны обрабатывать протокольные сообщения различных версий. Начиная с момента, когда версия протокола указывает возможности отправителя, прокси-сервер/шлюз никогда не должен посылать сообщения, версия которых больше, чем HTTP версия отправителя; если получена более высокая версия запроса, то прокси-сервер/шлюз должен или понизить версию запроса, вернув сообщение об ошибке, или переключиться на туннельное поведение. У запросов, версия которых ниже, чем HTTP версия прокси-сервера/шлюза можно перед пересылкой увеличить версию; ответ прокси-сервера/шлюза на этот запрос должен иметь ту же самую major версию, что и запрос.

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

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

URI известны под многими именами: WWW адреса, Универсальные Идентификаторы Документов, Универсальные Идентификаторы Ресурсов (URI), и, в заключение, как комбинация Единообразных Идентификаторов Ресурсов (Uniform Resource Locators, URL) и Единообразных Имен Ресурсов (Uniform Resource Names, URN). HTTP определяет URL просто как строку определенного формата, которая идентифицирует ресурс посредством имени, расположения, или любой другой характеристики.

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

URI в HTTP могут представляться в абсолютной форме (absolute URI) или относительно некоторого известного основного 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 )

escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" extra = "!" | "*" | "'" | "(" | ")" | "," safe = "$" | "-" | "_" | "." unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" national = <любой OCTET за исключением ALPHA, DIGIT, reserved, extra, safe, и unsafe октетов>

Полная информация о синтаксисе и семантике URL содержится в RFC 1738 и RFC 1808. Нормальная запись Бекуса-Наура включает национальные символы, недозволенные в правильных URL, определеных RFC 1738, так как HTTP серверы позволяют использовать для представления части rel_path адресов набор не зарезервированных символов, и, следовательно, HTTP прокси-сервера могут получать запросы URI, не удовлетворяющие 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 = <допустимое доменное имя машины или IP адрес (в точечно десятичной форме), как определено в разделе 2.1 RFC 1123>

port = *DIGIT

Если порт пуст или не задан - используется порт 80. Это означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса - abs_path. Использования IP адресов в URL следует избегать, насколько это возможно (RFC 1900). Если abs_path не представлен в URL, он должен рассматриваться как "/" при вычислении запрашиваемого URI (Request-URI) ресурса.

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

При сравнении двух URI, чтобы решить соответствуют ли они друг другу или нет, клиенту следует использовать чувствительное к регистру пооктетное (octet-by-octet) сравнение этих 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 (модифицированном RFC 822). Второй формат находится в общем пользовании, но основан на устаревшем и потерявшем статус стандарта RFC 850, описывающем форматы дат, он обладает тем недостатком, что год указывается не в четырехразрядной нотации. Клиенты и серверы HTTP/1.1, которые анализируют значение даты, должны понимать все три формата (для совместимости с HTTP/1.0), но генерировать для представления значений дат в полях заголовка HTTP должны только формат RFC 1123 .

Прис оздании приложений, желательно, чтобы оно умело воспринимать значения дат, которые, возможно, посланы не HTTP приложениями, а например SMTP или NNTP сообщений через прокси-сервера/шлюзы.

Все без исключений форматы даты/времени в 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"

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-ASCII до сложных методов, переключающих таблицы, наподобие тех, которые используют методики ISO 2022. Однако определение, связанное с именем кодовой таблицы MIME должно полностью определять отображение, которое преобразует октеты в символы. В частности использование внешней информации профилирования для определения точного отображения не разрешается.

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