RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

14.9.6. Расширения средств управления кэшем

Поле заголовка Cache-Control может распространяться с помощью одной или более лексем cache-extension, каждого с опциональным назначенным значением.

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

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

Например, рассмотрите гипотетическую новую директиву ответа под названием "community", который действует как модификатор к директиве "private". Мы определяем эту новую директиву, чтобы означать, что в дополнение к любому кэшу non-shared любой кэш, который разделен только членами community, названного в пределах его значения, может кэшировать ответ. Сервер происхождения, желающий позволить community "UCI" использовать иначе ответ private в их общедоступном кэше (ах), может сделать так, включая

Cache-Control: private, community="UCI"

Кэш, видя это поле заголовка будет действовать правильно, даже если кэш не поймет "community" cache-extension, так как он будет также видеть и понимать директиву "private" и таким образом значение по умолчанию к безопасному поведению. ДОЛЖНЫ быть проигнорированы нераспознанные директивы кэша; предположено, что любой cache-directive вероятно, чтобы быть нераспознанным HTTP/1.1 кэш будет объединен со стандартными директивами (или значение по умолчанию ответа cachability) таким образом, что поведение кэша останется минимально правильным, даже если кэш не поймет расширение (я).

2007 - 2017 © Русские переводы RFC, IETF, ISOC.