Согласование, управляемое агентом (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. протокольные особенности, позволяющие кэшу присоединить предупреждения к откликам, которые не сохраняют запрошенный уровень семантической прозрачности.

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

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

Корректность кэша

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

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

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

3. он включает в себя предупреждение о нарушении требований новизны клиента или исходного сервера;

4. это сообщение­отклик 304 (Not Modified), 305 (Proxy Redirect) или ошибка (4xx или 5xx).

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

Если кэш получает отклик (полный отклик или код 304 (Not Modified)), который уже не является свежим, кэш должен переадресовать его запросившему клиенту без добавления нового предупреждения и, не удаляя существующего заголовка Warning. Кэшу не следует пытаться перепроверить отклик, так как это может привести к бесконечному зацикливанию. Агент пользователя, который получает устаревший отклик без Warning, может отобразить предупреждение для пользователя.

Предупреждения

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

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

Предупреждения всегда допускают кэширование, так как они никогда не ослабляют прозрачности отклика. То есть, предупреждения могут передаваться HTTP/1.0 кэшам без опасения, что такие кэши просто передадут их как заголовки объектов отклика.

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

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

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

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

Механизмы управления кэшем

Базовым механизмом кэша в HTTP/1.1 являются неявные директивы кэша. В некоторых случаях серверу или клиенту может потребоваться выдать прямую директиву кэшу. Для этих целей используется заголовок Cache-Control.

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

Однако в некоторых случаях директивы Cache-Control сформулированы так, что явно ослабляют семантическую прозрачность (например, maxstale или public).