Согласование, управляемое агентом (Agentdriven Negotiation)

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

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

Согласование под управлением агента имеет и недостаток: требуется второй запрос для получения наилучшего альтернативного представления. Этот второй запрос эффективен только тогда, когда используется кэширование. Кроме того, эта спецификация не определяет какого-либо механизма поддержки автоматического выбора, хотя она и не препятствует применению любого такого механизма в рамках расширения HTTP/1.1.

HTTP/1.1 определяет статусные коды 300 (Multiple Choices — множественный выбор) и 406 (Not Acceptable — Не приемлем) для активации согласования под управлением агента, когда сервер не хочет или не может обеспечить свой механизм согласования.

Прозрачное согласование (Transparent Negotiation)

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

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

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

Кэширование в http

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

Кэширование представляется бесполезным, если оно значительно не улучшит работу. Целью кэширования в HTTP/1.1 является исключение во многих случаях необходимости посылать запросы, а в некоторых других случаях — полные отклики. При этом уменьшается число необходимых RTT для многих операций. Для этих целей используется механизм истечения срока (expiration). Одновременно снижаются требования к полосе пропускания сети, для чего применяется механизм проверки пригодности.

Требования к рабочим характеристикам, доступности и работе без соединения заставляют нас несколько снизить семантическую прозрачность. Протокол HTTP/1.1 позволяет исходным серверам, кэшам и клиентам снизить прозрачность, когда это необходимо. Так как непрозрачность операций может поставить в тупик недостаточно опытных пользователей, а также привести к определенной несовместимости для некоторых серверных приложений (таких, как торговля по заказу), протокол рекомендует не убирать прозрачность полностью, а лишь несколько ослабить. Следовательно, протокол HTTP/1.1 обеспечивает следующие важные моменты:

1. протокольные особенности, которые гарантируют полную семантическую прозрачность, когда этого требуют все участники процесса;

2. протокольные особенности, которые позволяют исходному серверу или агенту пользователя запросить и управлять непрозрачными операциями;

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

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

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