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

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

5.5.5. Рекурсивный режим работы сервера

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

- во всех ответах сервера устанавливается в "1" бит RA - рекурсия доступна.

- запрос клиента содержит бит RD - рекурсия желательна.

Если установлены оба бита RA и RD, то при необходимости используется режим рекурсии.

Возможны следующие варианты ответов:

1. Рекурсия разрешена

- ответ на запрос, возможно предшествуемый одной или двумя CNAME RR

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

- индикация временной ошибки

2. Рекурсия запрещена

- ошибка имени, указывающая, что имя не существует

- индикация временной ошибки

- некоторая комбинация:

RR, отвечающих на запрос вместе с информацией, являются ли эти RR кэшированными

Ссылка на сервер имен

- дополнительные RR, являющиеся по мнению сервера полезными запросчику.

Приложение 5

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

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

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

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

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

2. Функциональные требования к серверу HTTP

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

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

Сообщения HTTP должны передаваться с использованием виртуального соединения TCP.

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

При обмене сообщениями HTTP соединение должно инициироваться стороной клиента. Если сервер поддерживает стойкие соединения (см. п. 5.7.), то перед закрытием соединения он должен в сообщение ответа включить поле Connection с меткой close.

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

2.1.3. Если сервер поддерживает стойкие соединения, он должен обеспечивать функцию перекачки сообщений клиента в соответствии с п. 5.7.1.1.2.

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

3.1. Требования к элементам сообщений

3.1.1. В сообщении HTTP должен использоваться формат адреса URI в соответствии с п. 5.2.2.

3.1.2. В сообщении HTTP должен использоваться один из форматов представления даты, приведенных в п. 5.2.3.1.

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

3.2. Типы информации

3.2.1. Процедура согласования содержимого

3.2.1.1. Если сервер поддерживает управляемую сервером процедуру согласования содержимого, он должен использовать поле Vary для указания пределов варьирования представления ресурса. При осуществлении выбора представления сервер должен использовать информацию из полей Accept, Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges в соответствии с п. 5.12.1., 5.12.2., 5.12.3., 5.12.4., 5.12.5 .

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

3.2.2. Если сервер отправляет ответ с типом информации, отличным от application/octet-stream, он должен указать данный тип в поле Content-Type. Обозначение типа должно соответствовать RFC 2048 [15].

3.2.3. Если к телу сообщения применяется преобразование, тип преобразования должен быть указан в поле Transfer-Encoding в соответствии с п. 5.12.40.

3.3. Запросы

3.3.1. Структура запросов протокола HTTP должна соответствовать
п. 5.3.

3.3.2. В сервере должна быть реализована обработка запросов методами GET, HEAD.

3.3.2.1. Если в сервере реализована обработка условных запросов методами GET, HEAD, то для задания условия должны использоваться поля заголовка запроса:

If-Modified-Since;

If-Match;

If-None-Match;

If-Range;

If-Unmodified-Since.

При этом содержание полей должно обрабатываться согласно п. 5.12.24, 5.12.25, 5.12.26, 5.12.27, 5.12.28.

3.3.2.2. Если в сервере реализована обработка запросов диапазонов методом GET, то для задания диапазона должно использоваться поле Range. Содержимое поля Range должно интерпретироваться в соответствии с п. 5.12.36.

3.3.3. Для предоставления клиенту возможности запрашивать информацию о параметрах соединения с запрашиваемым URI должен использоваться метод OPTIONS (раздел 5.8.2).

3.3.4. Для предоставления клиенту возможности передачи на ресурс с указанным URI дополнительной информации в виде сущности должен использоваться метод POST (п. 5.8.5).

3.3.5. Для предоставления клиенту возможности сохранения на сервере сущности под указанным URI должен использоваться метод PUT (п. 5.8.6). Если в результате запроса клиента сервер создал новый ресурс, он должен выдать ответ 201. В случае невозможности сохранить сущность под указанным URI сервер должен выдать ответ 301.

3.3.6. Для предоставления клиенту возможности удаления ресурса с указанным URI должен использоваться метод DELETE (п. 5.8.7).

3.3.7. Метод TRACE используется для организации удаленного шлейфа (п. 5.8.8). Конечному получателю запроса следует направить полученное сообщение обратно клиенту в качестве тела сущности. При этом клиент должен выдать сообщение 200. Конечный получатель - это либо первоначальный сервер, либо первый прокси или шлюз для получения значения 0 в ответ. Запрос TRACE не должен включать сущность.

3.4. Ответы

3.4.1. Структура ответов сервера должна соответствовать п. 5.5.

3.4.2. Сервер должен поддерживать ответы с кодами статуса, приведенные в табл. 1.

Таблица 1

Ответы с кодами статуса.

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

3.4.4. В ответе сервера обязательно должно присутствовать поле Age, значение которого должно вычисляться согласно п. 5.12.6.

3.4.5. В ответе сервера обязательно должно присутствовать поле Date, содержащее дату и время генерации сообщения сервером.

3.5. Взаимодействие клиента и сервера

3.5.1. Сервер не должен выдавать ответ 100 клиенту с версией HTTP ниже 1.1.

4. Требования к реализации сервера HTTP

4.1. Требования к функциям кэша

4.1.1. Если в сервере реализованы функции кэша, они должны соответствовать п. 5.11.

4.1.2. Ответы на запрос с методом OPTIONS не должны кэшироваться.

4.1.3. Если кэш выдает устаревший ответ, в него должно быть включено предупреждение 10 (см. п. 5.12.45, табл. 3).

4.1.4. Если кэш не может провести проверку актуальности ответа, в данный ответ должно быть включено предупреждение 11 (см. п. 5.12.45, табл. 3).

4.1.5. Если кэш применяет преобразование содержимого тела сообщения, изменяющее его кодировку или тип информации, он должен включить в сообщение предупреждение 14 (см. п. 5.12.45, табл. 3).

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

4.2. Требования к функциям сервера прокси

4.2.1. Если в сервере реализованы функции сервера прокси, они должны соответствовать п. 5.11.

4.2.2. Сервер прокси не должен устанавливать стойкие соединения с клиентами версии HTTP/1.0. и ниже.

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

4.2.4. Если сервер прокси не выполняет функции межсетевого экрана, он должен добавлять в поле Via проходящих через него сообщений свой идентификатор в соответствии с п. 5.12.44. Если сервер прокси выполняет выполняет функции межсетевого экрана, то он должен иметь сертификат Гостехкомиссии России.

4.2.5. Если в прокси реализована процедура идентификации клиента, она должна выполняться с использованием полей заголовка Proxy-Authenticate и Proxy-Authorization в соответствии с п. 5.12.33. и 5.12.34.

4.2.6. Прокси должен добавлять в сообщение запроса поле Host, если данное поле отсутствует в сообщении.

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

4.3. Идентификация доступа

4.3.1. Для начала процедуры идентификации должен использоваться ответ 401 с полем WWW-Authenticate. В процедуре идентификации должно использоваться содержимое поля запроса Authorization. Если сервер не принимает сообщение клиента с полем Authorization, он снова должен выдать ответ 401.

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

4.4. Согласование протокола

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

5. Описание протокола HTTP

5.1. Базовые определения

Спецификация синтаксиса запросов и ответов HTTP приводится в расширенной форме Наура-Бекуса соответствующей RFC-822 [2].

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

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