Как обрабатывать кэш в файле .htaccess при использовании Service Worker - PullRequest
Новая
       9

Как обрабатывать кэш в файле .htaccess при использовании Service Worker

0 голосов
/ 04 февраля 2020

Я впервые кодирую PWA и задаюсь вопросом, не противоречит ли моя политика кэширования .htaccess с моей политикой Service Worker Stategies. Вот как это выглядит в моем .htaccess файле 

<IfModule mod_expires.c>

    ExpiresActive on

    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/gif "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"

    ExpiresByType text/css "access plus 1 days"
</IfModule>

Должен ли я удалить эту часть, чтобы мой Service Worker правильно обрабатывал кэш?

1 Ответ

0 голосов
/ 04 февраля 2020

Значение слова «конфликт» здесь не очень понятно. Это полностью зависит от того, что вы подразумеваете под этим. С уверенностью 99,99% нет никакого «конфликта» любого рода, это по сути отдельные технологии, которые не наступают друг другу на ноги. Имейте в виду, что Service Worker - это интерфейс с поддержкой сценариев, поэтому нет ни одного Service Worker. Ваш SW может сделать что-то совершенно другое, чем мое.

Хорошо помнить, что кэши работают следующим образом:

Без Service Worker: Браузер <-> HTTP-кеш браузера (HTTP-заголовки) <-> HTTP-сервер

С Service Worker: Browser <-> Service Worker <-> HTTP-кеш браузера (HTTP-заголовки) <-> HTTP-сервер

Теперь, в вашем случае, .htaccess - это то, что присоединяет HTTP кэширование заголовков ответов, обслуживаемых вашим HTTP-сервером. Таким образом, эти заголовки кэширования будут видны работнику сервиса, когда он связывается с HTTP-сервером. Они не "конфликтуют". Они не типа "или / или" ситуации. Они делают разные вещи.

Пример:

  1. На сервере установлено приложение. css
  2. Браузер запрашивает приложение. css
  3. Service Worker видит запрос на приложение. css
  4. Service Worker отправляет запрос на HTTP-сервер
  5. Запрос проходит через HTTP-интерфейс браузера и кеш
  6. HTTP-сервер отвечает с приложением. css и говорит: «Кэшируйте это на один месяц!»
  7. Ответ возвращается через HTTP-интерфейс браузера и сохраняется в кеше HTTP
  8. Service Worker , возможно, делает что-то с ответом
  9. Service Worker перенаправляет ответ обратно в браузер
  10. В браузере теперь есть приложение. css

Пункт 8: на этом Точка Обычно SW кэширует ответ в Cache API (это отдельный, а не HTTP-кэш). Точка 3: в этот момент обычно SW проверяет Cache API, чтобы увидеть, был ли уже кеширован запрос (если это произошло выше). Если Cache API предоставляет ответ, SW пропускает шаги 4–8 и просто отвечает кэшированной версией.

Но, поскольку Serwice Worker может работать с сценариями, он может делать что-то другое.

I ДЕЙСТВИТЕЛЬНО РЕКОМЕНДУЕТЕ прочитать этот пост в блоге о различных схемах кэширования HTTP и о том, как они работают с Service Worker: https://jakearchibald.com/2016/caching-best-practices/

...