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

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

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

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

Прямые предупреждения агента пользователя

Многие агенты пользователя позволяют переписывать базовый механизм кэширования. Например, агент пользователя может специфицировать, какие кэшированные объекты (даже явно старые) не проверять на новизну. Или агент пользователя может всегда добавлять "Cache-Control: maxstale=3600" к каждому запросу.

Если пользователь переписал базовый механизм кэширования, агент пользователя должен явно указывать всякий раз, когда это важно, что отображаемая информация не отвечает требованиям прозрачности (в частности, если отображаемый объект известен как устаревший). Так как протокол обычно разрешает агенту пользователя определять, является ли отклик устаревшим, эта индикация нужна только тогда, когда такое действительно случится. Для индикации не нужно диалоговое окно; это может быть иконка (например, изображение гнилой рыбы) или какой­то иной визуальный индикатор.

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

Исключения для правил и предупреждений

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

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

Работа под управлением клиента

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

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

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