Условия пригодности

Принцип использования меток объектов базируется на том, что только автор услуг знает семантику ресурсов достаточно хорошо, чтобы выбрать подходящий механизм контроля кэширования. Спецификация любой функции сравнения валидаторов более сложна, чем сравнение байтов. Таким образом, для целей проверки пригодности записи в кэше никогда не используется сравнение любых других заголовков кроме Last-Modified, для совместимости с HTTP/1.0.

Кэшируемость отклика

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

Заметьте, что некоторые кэши HTTP/1.0 нарушают эти правила, даже не присылая предупреждения.

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

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

Отклик, полученный со статусным кодом 200, 203, 206, 300, 301 или 410, может быть запомнен кэшем и использован в ответе на последующие запросы, если директива не препятствует кэшированию. Однако кэш, который не поддерживает заголовки Range и ContentRange, не должен кэшировать отклики 206 (Partial Content).

Отклик, полученный с любым другим статусным кодом, не должен отсылаться в ответ на последующие запросы, если только нет директив Cache-Control или других заголовков, которые напрямую разрешают это. К таким, например, относятся: заголовок Expires; maxage, mustrevalidate, proxyrevalidate, public или private директива Cache-Control.

Формирование откликов кэшей

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

Заголовки End-to-end (точка­точка) и Hop-by-hop (шаг­за-шагом)

Для определения поведения кэшей и некэширующих проксисерверов заголовки HTTP делят на две категории.

• Заголовки End-to-end, которые должны быть пересланы конечному получателю запроса или отклика. Такие заголовки в откликах должны запоминаться как часть объекта кэша и пересылаться в любом отклике, полученном из записи кэша.

• Заголовки Hop-by-hop, которые имеют смысл только для одноуровневого транспортного соединения, они не запоминаются кэшем и не переадресуются проксисерверами.

Следующие заголовки HTTP/1.1 относятся к категории hop-by-hop:

• Connection

• Keep-Alive

• Public

• Proxy-Authenticate

• Transfer-Encoding

• Upgrade

Все другие заголовки, определенные HTTP/1.1, относятся к категории end-to-end. Заголовки Hop-by-hop должны быть перечислены в заголовке Connection.