odpowiedź w pamięci podręcznej skrzynki roboczej

Jeśli zasoby są buforowane w czasie działania, nie ma uniwersalnej reguły, która decydowałaby, czy dana odpowiedź to „prawidłowy” oraz możliwość ich zapisania i ponownego wykorzystania.

Moduł workbox-cacheable-response zapewnia standardowy sposób określania, czy odpowiedź powinna zostać zapisana w pamięci podręcznej na podstawie kodu stanu numerycznego, obecności nagłówka z określoną wartością lub kombinacji tych dwóch elementów.

Buforowanie na podstawie kodów stanu

Możesz skonfigurować strategię obszaru roboczego, którą warto rozważyć: zestawu kodów stanu jako kwalifikujących się do buforowania, dodając CacheableResponsePlugin wystąpienie do parametru plugins strategii:

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) =>
    url.origin === 'https://third-party.example.com' &&
    url.pathname.startsWith('/images/'),
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

Ta konfiguracja informuje Workbox, że podczas przetwarzania odpowiedzi na żądania dotyczące https://third-party.example.com/images/ należy przechowywać w pamięci podręcznej wszystkie żądania z kodem stanu 0 lub 200.

Buforowanie na podstawie nagłówków

Możesz skonfigurować strategię obszaru roboczego, aby sprawdzić, obecności określonych wartości nagłówka jako kryteriów dodawania do pamięci podręcznej przez ustawienie obiektu headers podczas tworzenia wtyczki:

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

Podczas przetwarzania odpowiedzi na żądania z adresami URL zawierającymi /path/to/api/ sprawdź nagłówek o nazwie X-Is-Cacheable (zostanie on dodany do odpowiedzi przez serwer). czy ten nagłówek występuje i czy występuje w niej; ma wartość „true” (prawda), odpowiedź może być zapisywana w pamięci podręcznej.

Jeśli podano kilka nagłówków, tylko jeden z nich musi być zgodny z powiązanymi wartościami.

Buforowanie na podstawie nagłówków i kodów stanu

Możesz stosować dowolne kombinacje stanów i konfiguracji nagłówka. Aby odpowiedź mogła zostać uznana za nadającą się do zapisania w pamięci podręcznej, muszą być spełnione oba te warunki. Innymi słowy, odpowiedź musi zawierać jeden z skonfigurowanych kodów stanu oraz co najmniej 1 z podanych nagłówków.

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200, 404],
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

Jakie są domyślne wartości?

Jeśli używasz jednej z wbudowanych strategii Workbox bez podczas konfigurowania cacheableResponse.CacheableResponsePlugin zostaną zastosowane następujące kryteria domyślne używany do określenia, czy odpowiedź otrzymana z sieci powinna zapisać w pamięci podręcznej:

• staleWhileRevalidate i networkFirst: odpowiedzi o stanie 0 (czyli nieprzejrzystych odpowiedzi) lub 200 są uważane za nadające się do zapisania w pamięci podręcznej.
• cacheFirst: odpowiedzi o stanie 200 są uważane za możliwe do buforowania.

Domyślnie nagłówki odpowiedzi nie są używane do określania możliwości buforowania.

Dlaczego występują różne wartości domyślne?

Domyślne wartości zależą od tego, czy odpowiedzi o stanie 0 (czyli nieprzejrzystych odpowiedzi) zostaną zapisane w pamięci podręcznej. Z powodu „czarnego skrzynki” nieprzejrzyste odpowiedzi nie jest możliwe, aby skrypt service worker wiedział, czy odpowiedź jest prawidłowy lub czy odzwierciedla odpowiedź błędu zwróconą przez między domenami.

W przypadku strategii, które obejmują pewne sposoby aktualizowania odpowiedzi z pamięci podręcznej, np. staleWhileRevalidate i networkFirst, ryzyko załadowania do pamięci podręcznej tymczasowej odpowiedzi z błędem jest ograniczone przez fakt, że przy następnej aktualizacji pamięci podręcznej zostanie użyta prawidłowa, pomyślna odpowiedź.

W przypadku strategii, które polegają na przechowywaniu w pamięci podręcznej pierwszej otrzymanej odpowiedzi i jej wielokrotnym wykorzystywaniu, konsekwencje tymczasowego błędu w pamięci podręcznej i jego ponowne wykorzystanie są poważniejsze. Aby popełniać błędy dla bezpiecznego przechowywania danych, domyślnie cacheFirst odrzuca zapisanie odpowiedzi, chyba że ma kod stanu 200.

Zaawansowane użycie

Jeśli chcesz używać tej samej logiki buforowania poza strategią Workbox, możesz bezpośrednio użyć klasy CacheableResponse.

import {CacheableResponse} from 'workbox-cacheable-response';

const cacheable = new CacheableResponse({
  statuses: [0, 200],
  headers: {
    'X-Is-Cacheable': 'true',
  },
});

const response = await fetch('/path/to/api');

if (cacheable.isResponseCacheable(response)) {
  const cache = await caches.open('api-cache');
  cache.put(response.url, response);
} else {
  // Do something when the response can't be cached.
}