Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 19)

Прокси, получивший запрос с полем Max-Forwards=0, не должен направлять данное сообщение, а должен выдать ответ 200.

5.12.32. Pragma

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

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

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

extension-pragma ::= token [ "=" ( token | quoted-string ) ]

Директивы Pragma должны передаваться без изменения через прокси или шлюз, вне зависимости от их значения для данного прокси или шлюза.

5.12.33. Proxy-Authenticate

Поле заголовка ответа Proxy-Authenticate должно быть включено в ответ 407. Значение данного поля состоит из вызова, указывающего схему идентификации и параметры, применимые к прокси, имеющему данный Request-URI.

Proxy-Authenticate ::= "Proxy-Authenticate" ":" challenge

5.12.34. Proxy-Authorization

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

Proxy-Authorization ::= "Proxy-Authorization" ":" credentials

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

5.12.35. Public

Поле заголовка Public ответа содержит перечень методов, поддерживаемых сервером. Данное поле может использоваться совместно с полем Allow, которое в свою очередь перечисляет методы, применимые для конкретного Request-URI.

Public ::= "Public" ":" 1#method

Данное поле применимо только к серверу, имеющему непосредственное соединение с клиентом.

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

5.12.36. Range

5.12.36.1. Диапазоны байтов

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

Операция выделения диапазона байтов может определять один или несколько диапазонов байтов внутри одной сущности.

ranges-specifier ::= byte-ranges-specifier

byte-ranges-specifier ::= bytes-unit "=" byte-range-set

byte-range-set ::= 1#( byte-range-spec | suffix-byte-range-spec )

byte-range-spec ::= first-byte-pos "-" [last-byte-pos]

first-byte-pos ::= 1*DIGIT

last-byte-pos ::= 1*DIGIT

suffix-byte-range-spec ::= "-" suffix-length

suffix-length ::= 1*DIGIT

где

first-byte-pos – смещение первого байта диапазона,

last-byte-pos – смещение последнего байта в диапазоне. Диапазон определяется от поля first-byte-pos до last-byte-pos включительно. Смещение отсчитывается от нулевого байта сущности.

Получатель неправильно определенного диапазона должен его игнорировать.

С помощью поля suffix-byte-range-spec можно указать N последних байтов сообщения.

При превышении значением suffix-byte-range-spec длины сущности, диапазон определяет всю сущность.

5.12.36.2. Запросы на получение диапазона

Запрос на получение диапазона должен использовать условный или безусловный метод GET. Для определения диапазона используется поле заголовка запроса Range.

Range ::= "Range" ":" ranges-specifier

При выдаче успешного ответа на запрос с определенным диапазоном сервер должен использовать ответ 206.

5.12.37. Referer

Поле заголовка запроса Referer позволяет клиенту указать адрес (URI) ресурса, от которого был получен Request-URI.

Данное поле не должно включаться в заголовок, если источник, от которого был получен Request-URI, не имеет собственного URI (например, если Request-URI был введен с консоли пользователя).

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

Например:

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

URI, указанное в поле Referer, не должно быть URI фрагмента. Для относительного URI в качестве базы должен использоваться Request-URI.

Рекомендуется, чтобы клиент имел возможность включать/отключать отправку поля Referer в запросах.

5.12.38. Retry-After

Поле заголовка ответа Retry-After может использоваться с ответом 503 для указания того, насколько долго сервис будет недоступен данному клиенту.

Retry-After ::= "Retry-After" ":" ( HTTP-date | delta-seconds )

5.12.39. Server

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

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

Прокси не должен изменять заголовок Server при направлении ответа.

Прокси может включить поле Via для идентификации самого себя в качестве прокси, направившего ответ.

5.12.40. Transfer-Encoding

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

Transfer-Encoding ::= "Transfer-Encoding" ":"

1#transfer-coding

5.12.41. Upgrade

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

Upgrade ::= "Upgrade" ":" 1#product

Ответ 101 с полем Upgrade должен быть первым ответом сервера после переключения на альтернативный протокол по запросу клиента с полем Upgrade.

Согласование протокола с использованием поля Upgrade применимо только для текущего соединения транспортного уровня.

Поле заголовка Upgrade должно использоваться внутри поля заголовка Connection.

5.12.42. User-Agent

Поле заголовка запроса User-Agent содержит информацию о программном обеспечении клиента, выдавшего запрос. Клиенты не обязательно должны включать данное поле в запрос.

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

5.12.43. Vary

Поле заголовка ответа Vary используется сервером, чтобы сигнализировать, что сущность, содержащаяся в ответе, была выбрана из ряда доступных представлений с использованием механизма управляемого сервером согласования содержимого. Перечень полей, содержащихся в данном поле, указывает на размерность варьирования представления ресурса. Символ “*” указывает на то, что размерность варьирования не определена.

Vary ::= "Vary" ":" ( "*" | 1#field-name )

Поле Vary должно включаться в каждый кэшируемый ответ, являющийся предметом управляемого сервером согласования содержимого.

Поле Vary может включаться в некэшируемый ответ, являющийся предметом управляемого сервером согласования содержимого.

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

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

5.12.44. Via

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

Via ::= "Via" ":" 1#( received-protocol received-by [ comment ] )

received-protocol ::= [ protocol-name "/" ] protocol-version

protocol-name ::= token

protocol-version ::= token

received-by ::= ( host [ ":" port ] ) | pseudonym

pseudonym ::= token

Если протоколом является HTTP, тогда (и только тогда) received-protocol может не указываться. Вместо настоящего имени узла может указываться псевдоним.

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

По умолчанию port=80.

Добавление информации в поле Via является необязательным.

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

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

5.12.45. Warning

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

Warning ::= "Warning" ":" 1#warning-value

warning-value ::= warn-code SP warn-agent SP warn-text

warn-code ::= 2DIGIT

warn-agent ::= ( host [ ":" port ] ) | pseudonym

; имя или псевдоним сервера, добавившего

; поле заголовка Warning

warn-text ::= quoted-string

Если в тесте warn-text используется набор символов, отличный от ISO-8859-1 [16], текст должен быть закодирован в соответствии с RFC 2047 [17].

Кэш не должен удалять поля Warning. Но при проверке актуальности позиции кэш должен удалить все поля Warning, ранее присоединенные к данному сообщению. Коды warn-code приведкны в табл. 3.

Таблица 3

Коды предупреждений warn-code

5.12.46. WWW-Authenticate

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

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

Приложение 6

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу NNTP

1. Область применения

Настоящее приложение описывает технические требования к ТС службы доступа к информационным ресурсам а по протоколу NNTP в соответствии с RFC 977 [26].

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

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

2. Функциональные требования к взаимодействию клиента NNTP и сервера NNTP

2.1. Соединения

2.1.1. Протокол нижнего уровня

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

При использовании TCP каждый семибитный символ, передаваемый по соединению TCP должен передаваться в отдельном октете. При этом символ должен быть выровнен вправо, а старший бит октета установлен в 0.

2.1.2. Установление соединения и закрытие соединения

Клиент должен инициировать установление соединения протокола нижнего уровня. После установления соединения сервер должен выдать ответ 200 либо 201.

Закрытие соединения осуществляется в следующей последовательности: клиент выдает команду QUIT, сервер выдает ответ 205, сервер разрывает соединение протокола нижнего уровня.

3. Перечень и структура сообщений протокола NNTP

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

Сообщения NNTP подразделяются на команды и ответы .

3.1. Команды

3.1.1. Структура команд

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

Различие между строчными и прописными символами в кодах команд и аргументах команд является несущественным.

Каждая команда должна заканчиваться символами .

Характеристики

Список файлов стандарта