радиолиниями и неустойчивой связью. Цель HTTP/1.1 состоит в поддержании
широкого многообразия конфигураций, уже построенных при введении ранних
версий протокола, а также в удовлетворении потребностей разработчиков web
приложений, требующих все более высокой надежности.
HTTP соединение обычно происходит посредством TCP/IP соединений.
Заданный по умолчанию порт TCP - 80, но могут использоваться и другие порты
(например: 8080, 8081). HTTP также может быть реализован посредством любого
другого протокола Интернет, или других сетей. HTTP необходима только
надежная передача данных, следовательно может использоваться любой
протокол, который гарантирует надежную передачу данных; отображение
структуры запроса и ответа HTTP/1.1 на транспортные модули данных
рассматриваемого протокола - вопрос, не решается на уровне самого
протокола.
Большинство реализаций HTTP/1.0 использовало новое соединение для
каждого обмена запросом/ответом. В HTTP/1.1, установленное соединение может
использоваться для одного или нескольких обменов запросом/ответом, хотя
соединение может быть закрыто по ряду причин.
3. Параметры протокола.
3.1 Версия HTTP.
HTTP использует схему нумерации типа ".", для указания
версии протокола. Стратегия версификации протокола предназначена для того,
чтобы позволить отправителю указать формат сообщения и свои способности
понимания для дальнейшей HTTP связи, прежде чем он получит что-либо
посредством этой связи. При добавлении компонентов сообщения, которые не
воздействуют на процесс связи, или компонентов, которые добавляются только
к расширяемым значениям поля, номер версии не меняется. Когда внесенные в
протокол изменения добавляют возможности, которые не изменяют общий
алгоритм анализа сообщений, но расширяют семантику сообщения и
подразумевают дополнительные возможности отправителя, увеличивается
номер. Когда изменяется формат сообщения протокола увеличивается
номер.
Версия HTTP сообщения обозначается полем HTTP-version в первой строке
сообщения.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Major и minor числа должны обрабатываться как отдельные целые числа и
что каждое может состоять более чем из одной цифры. Таким образом, HTTP/2.4
- более низкая версия, чем HTTP/2.13, которая в свою очередь ниже чем
HTTP/12.3. Нули должны игнорироваться получателями и не должны посылаться.
Приложения, посылающие сообщения запросов или ответов, которые
описывает спецификация HTTP/1.1, должны указывать версию HTTP (HTTP-
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 )
pchar = uchar | ":" | "@" | "&" | "=" | "+" uchar = unreserved |
escape unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" |
"=" | "+" extra = "!" | "*" | "'" | "(" | ")" | "," safe = "$" | "-" |
"_" | "." unsafe = CTL | SP | | "#" | "%" | "" national =
Полная информация о синтаксисе и семантике 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 =
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). В первых двух форматах данный
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
