Побочные эффекты методов get и head

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

Обратим внимание только на одно исключение из этого правила: некоторые приложения имеют традиционно используемые GET и HEAD с запросами URL, содержащими "?" в части rel_path. Кэши не должны обрабатывать отклики от таких URL как свежие, если только сервер не присылает непосредственно значение времени жизни. Это, в частности, означает, что отклики от серверов HTTP/1.0 для этих URI не следует брать из кэша.

Несоответствие после актуализации или стирания

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

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

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

Некоторые методы HTTP могут сделать объект непригодным. Это объекты, на которые осуществляется ссылка либо через Request-URI, либо через заголовки отклика Location или Content-Location (если они имеются). Это методы:

• PUT

• DELETE

• POST

Обязательная пропись (Write-Through Mandatory)

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

Альтернатива, известная как writeback или copyback кэширование, в HTTP/1.1 не допускается изза трудности обеспечения согласованных актуализаций и проблем, связанных с отказами сервера, кэша или сети до осуществления обратной записи (writeback).

Замещения в кэше

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

Замечание. Новый отклик, который имеет значение заголовка Date старше, чем кэшированные уже отклики, не должен заноситься в кэш.