Как работает валидация в случае кеша браузера, кеша прокси и исходного сервера? - PullRequest
Новая
       43

Как работает валидация в случае кеша браузера, кеша прокси и исходного сервера?

0 голосов
/ 05 июня 2018

См .: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Freshness

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

Предположим, у нас есть: кеш браузера, прокси-кеш и исходный сервер.:

  • Кэш браузера содержит сохраненный устаревший ресурс с тегом сущности «A».
  • Кэш-прокси содержит сохраненный устаревший ресурс с тегом сущности «B».Прокси-кеш может действовать как клиент и как сервер.

Это может быть, например, случай, если вы только начинаете использовать прокси-кеш.Что произойдет в этом случае?

  • Браузер отправит условный запрос с If-None-Match: "A".
  • Кэш-прокси получает условный запрос.
  • Прокси-кеш перенаправит этот запрос (согласно приведенной выше цитате).Это связано с тем, что хранимый ресурс в прокси-кэше устарел.
  • Исходный сервер получает запрос с тегом сущности "A".

Допустим, ресурс на источникеСервер содержит сущность-тег «А».Теперь сервер ответит ответом 304 Not Modified.

На данный момент я больше ничего не понимаю, поэтому, может быть, я что-то не так понял раньше?Ответ 304 подходит для кэша браузера, поскольку он содержит тот же ресурс, что и на исходном сервере (тот же тег объекта).Однако прокси-кеш содержит более старый ресурс (с другим Etag).Если прокси-кеш получит ответ 304 (и обновит свои метаданные), то прокси-кеш снова сделает ресурс действительным, пока он старый.

Это нежелательно, поэтому, возможно, я где-то допустил ошибку?Как это на самом деле работает?Как мне увидеть этот процесс?

1 Ответ

0 голосов
/ 07 июня 2018

Ознакомьтесь с разделом 4.3 спецификации RFC7234.В частности, в разделе 4.3.2 говорится следующее:

Когда кэш принимает решение о повторной проверке собственных хранимых ответов на запрос, содержащий список тегов сущности If-None-Match, кеш МОЖЕТ объединитьсяполученный список со списком тегов сущностей из его собственного сохраненного набора ответов (свежих или устаревших) и отправка объединения двух списков в качестве значения поля заголовка замены If-None-Match в перенаправленном запросе.Если сохраненный ответ содержит только частичное содержимое, кеш НЕ ДОЛЖЕН включать свой тег объекта в объединение, если только запрос не соответствует диапазону, который будет полностью удовлетворен этим частичным сохраненным ответом.Если ответ на перенаправленный запрос равен 304 (не изменен) и имеет значение поля заголовка ETag с тегом объекта, которого нет в списке клиента, кэш ДОЛЖЕН сгенерировать ответ 200 (ОК) для клиента путем повторного использования его соответствующегосохраненный ответ, обновленный метаданными ответа 304 (раздел 4.3.4).

Таким образом, прокси-сервер может отправлять оба тега объекта (A и B) на сервер источника для проверки.Если представление ресурса не изменилось, исходный сервер отправит ответ 304.Если тег объекта в этом ответе равен B, прокси-сервер может освежить свой устаревший, сохраненный ответ и использовать его для отправки ответа 200 OK клиенту.Получив этот новый ответ, браузер может обновить свой кэш вместе с ним.

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

...