Сети и системы телекоммуникаций. Погонин В.А - 80 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

HTTP/2.13, которая, в свою очередь, ниже чем HTTP/12.3. Нули должны игнорироваться получа-
телями и не должны посылаться.
Приложения, посылающие сообщения запросов или ответов, которые описывает специфика-
ция HTTP/1.1, должны указывать версию HTTP (HTTP-version) "HTTP/1.1". Использование этого
номера версии указывает, что посылающее приложение, по крайней мере, условно совместимо с
этой спецификацией.
HTTP версия приложения – это самая высокая HTTP версия, с которой приложение является,
по крайней мере, условно совместимым с ним.
Приложения, реализующие прокси-сервера и шлюзы, должны обрабатывать протокольные
сообщения различных версий. Начиная с момента, когда версия протокола указывает возможно-
сти отправителя, прокси-сервер/шлюз никогда не должен посылать сообщения, версия которых
больше, чем HTTP версия отправителя; если получена более высокая версия запроса, то прокси-
сервер/шлюз должен или понизить версию запроса, вернув сообщение об ошибке, или переклю-
читься на туннельное поведение. У запросов, версия которых ниже, чем HTTP версия прокси-
сервера/шлюза, можно перед пересылкой увеличить версию; ответ прокси-сервера/шлюза на этот
запрос должен иметь ту же самую major версию, что и запрос.
Преобразование версий HTTP может включать модификацию полей заголовка, требуемых
или запрещенных этими версиями.
URI известны под многими именами: WWW адреса, Универсальные Идентификаторы Доку-
ментов, Универсальные Идентификаторы Ресурсов (URI), и, в заключение, как комбинация Еди-
нообразных Идентификаторов Ресурсов (Uniform Resource Locators, URL) и Единообразных Имен
Ресурсов (Uniform Resource Names, URN). HTTP определяет URL просто как строку определенно-
го формата, которая идентифицирует ресурс посредством имени, расположения, или любой дру-
гой характеристики.
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 = <любой 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

Страницы