Если вы используете Cache Storage API либо внутри сервис-воркера, либо непосредственно из веб-приложений через window.caches
, есть хорошие новости: начиная с Chrome 54 поддерживается полный набор CacheQueryOptions
, что упрощает поиск кэшированных ответов, которые вы используете. ищешь.
Какие варианты доступны?
Следующие параметры можно установить при любом вызове CacheStorage.match()
или Cache.match()
. Если они не установлены, все они по умолчанию имеют значение false
(или undefined
для cacheName
), и вы можете использовать несколько параметров в одном вызове match()
.
ignoreSearch
Это указывает алгоритму сопоставления игнорировать поисковую часть URL-адреса, также известную как параметры запроса URL-адреса. Это может пригодиться, если у вас есть исходный URL-адрес, содержащий параметры запроса, которые используются, например, для аналитического отслеживания, но не важны с точки зрения уникальной идентификации ресурса в кеше. Например, многие люди стали жертвами следующей ошибки сервис-воркера:
self.addEventListener('install', event => {
event.waitUntil(
caches.open('my-cache')
.then(cache => cache.add('index.html'))
);
});
self.addEventListener('fetch', event => {
// Make sure this is a navigation request before responding.
if (event.request.mode === 'navigation') {
event.respondWith(
caches.match(event.request) || fetch(event.request)
);
}
});
Этот тип кода работает, как и ожидалось, когда пользователь переходит непосредственно к index.html
, но что, если ваше веб-приложение использует поставщика аналитики для отслеживания входящих ссылок, а пользователь переходит к index.html?utm_source=some-referral
? По умолчанию передача index.html?utm_source=some-referral
в caches.match()
не возвращает запись для index.html
. Но если ignoreSearch
имеет значение true
, вы можете получить ожидаемый кэшированный ответ независимо от того, какие параметры запроса установлены:
caches.match(event.request, {ignoreSearch: true})
cacheName
cacheName
пригодится, если у вас есть несколько кешей и вам нужен ответ, хранящийся в одном конкретном кеше. Его использование может сделать ваши запросы более эффективными (поскольку браузеру нужно проверять только один кеш, а не все из них) и позволяет вам получить конкретный ответ для данного URL-адреса, когда несколько кешей могут иметь этот URL-адрес в качестве ключа. cacheName
имеет эффект только при использовании с CacheStorage.match()
, а не Cache.match()
, поскольку Cache.match()
уже работает с одним именем, имеющим имя кэшированного.
// The following are functionally equivalent:
caches.open('my-cache')
.then(cache => cache.match('index.html'));
// or...
caches.match('index.html', {cacheName: 'my-cache'});
ignoreMethod
и ignoreVary
ignoreMethod
и ignoreVary
являются немного более нишевыми, чем ignoreSearch
cacheName
, но они служат конкретным целям.
ignoreMethod
позволяет вам передать объект Request
, имеющий любой method
( POST
, PUT
и т. д.), в качестве первого параметра для match()
. Обычно разрешены только запросы GET
или HEAD
.
// In a more realistic scenario, postRequest might come from
// the request property of a FetchEvent.
const postRequest = new Request('index.html', {method: 'post'});
// This will never match anything.
caches.match(postRequest);
// This will match index.html in any cache.
caches.match(postRequest, {ignoreMethod: true});
Если установлено значение true
, ignoreVary
означает, что поиск в кэше будет выполняться без учета каких-либо заголовков Vary
, установленных в кэшированных ответах. Если вы знаете, что не имеете дело с кэшированными ответами, использующими заголовок Vary, вам не нужно беспокоиться об установке этой опции.
Поддержка браузера
CacheQueryOptions
актуален только в браузерах, поддерживающих API Cache Storage. Помимо Chrome и браузеров на основе Chromium, в настоящее время это ограничено Firefox, который уже изначально поддерживает CacheQueryOptions
.
Разработчики, желающие использовать CacheQueryOptions
в версиях Chrome до 54, могут использовать полифилл , любезно предоставленный Артуром Столяром .