Кэширование откликов рабочих рабочих служб

Question

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

Как правило, при использовании сервисного работника кеш-страница полностью обходит?

Должен ли я создать фреймворк для обработки истечения ресурса/аннулирования, например, кеша http, который использовался для нас? Или я говорю мусор?

Было бы очень полезно, если бы кто-то мог пояснить это. Как я вижу, есть 3 потенциальных сценария:

A). Запрос сети => Служебный сотрудник fetch => (кеш браузера?) < => Сервер

B). Сетевой запрос < => (кеш браузера?) < => Рабочий рабочий выбор < => Сервер

C). Запрос сети => Извлечение рабочего рабочего < => Сервер

Я тестировал это локально, и кажется, что C). является правильной реализацией, при которой разработчик жертвовал абзацем заголовка кэша/длительностью для контроля.

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

Answer 1

A) - это правильная модель. Если рабочий-оператор управляет страницей, все сетевые запросы будут запускать обработчик событий fetch обслуживающего работника до консультации с кешем браузера или сетью.

В свою очередь, в любое время работник службы делает запрос сети, либо в явном виде через fetch() или неявно с помощью cache.add()/cache.addAll(), «традиционный» кэш браузера консультируются для ответа первого. Сетевой запрос на сервер будет выполнен только в том случае, если в кеше браузера нет действительного ответа.

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

Существует очень подробное объяснение этого взаимодействия на https://jakearchibald.com/2016/caching-best-practices/, в частности на покрытие things to avoid и ways to take advantage of this behavior.

Answer 2

Это зависит от способа настройки запроса. С помощью API-интерфейса Fetch вы можете контролировать, как запрос взаимодействует с HTTP-кешем браузера.

Например, вы можете установить режим кэширования запроса на no-store, чтобы он обходил HTTP-кеш. Или вы можете установить режим кэширования запроса на force-cache так браузера будет возвращать кэшированный ответ, даже если он несвежий:

fetch("some.json", {cache: "force-cache"}) 
    .then(function(response) { /* consume the response */ }); 

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

Для получения дополнительной информации проверьте Fetch Standard, Request.cache MSN page и Using Service Workers MDN page.