Управление кэшем и параметры заголовка/формы/запроса

Question

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

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

Существует ли какой-либо окончательный список действий по управлению кешем, который представляет собой «кеш-хит» и что представляет собой «пропущен кеш»?

Некоторых различных факторов, я могу в настоящее время думать:

1. Query parameter keys
2. параметра запроса значения
3. ключей параметров Формы
4. параметра формы значения
5. ключей параметров заголовка
значений параметров
6. заголовка

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

Из некоторых исследований, которые я сделал, факторы 1 и 2, по-видимому, оцениваются при определении того, что что-то попало в кеш.

А как насчет других?

Answer 1

См. RFC 7234 для спецификации.

В частности:

Ключ первичного кэша состоит из метода запроса и целевого URI.

отметить также, что:

Сталкиваясь с просьбой, кэш ДОЛЖЕН НЕ повторно использовать сохраненный ответ, если: ... выбирающих полей заголовка, выдвигаемых хранимого ответ (если таковые имеются) матч представленных (см раздел 4.1)

, а также:

Когда кэш получает запрос, который может быть удовлетворен сохраненным ответом , который имеет поле заголовка Vary (раздел 7.1.4 в [RFC7231]), , он НЕ ДОЛЖЕН использовать этот ответ, если все поля заголовка выбора номинированное знаком поля заголовка Vary как в исходном запросе (т. е. связанном с сохраненным ответом), так и в запросе .

То есть, заголовки считаются не значимыми, если сервер не отвечает Vary: и указывает этот заголовок.