Как откатиться к браузерной обработке выборки по умолчанию в event.respondWith ()? - PullRequest
Новая
       18

Как откатиться к браузерной обработке выборки по умолчанию в event.respondWith ()?

0 голосов
/ 27 апреля 2018

В сервисном работнике мой обработчик выборки выглядит так: 

self.addEventListener('fetch', function (event) {
  event.respondWith(
    caches.match(event.request).then(function (response) {
      return response || fetch(event.request); //<-- is this the browser's default fetch handling?
    })
  );
});

Метод event.respondWith () заставляет меня обрабатывать все запросы самостоятельно, включая запросы xhr, что мне не нравится. Я только хочу, чтобы кэшированные ресурсы возвращались, если они доступны, и позволяю браузеру обрабатывать все остальное, используя обработку выборки по умолчанию.

У меня две проблемы с fetch(event.request):

  1. Только при открытии devtools выдает ошибку при получении начального URL, который отображается в адресной строке https://test.de/x/#/page. Это происходит как при начальной установке, так и при каждой перезагрузке:

    Uncaught (в обещании) TypeError: Не удалось выполнить 'fetch' для 'ServiceWorkerGlobalScope': 'only-if-cached' можно установить только в режиме 'same-origin' '

    и я не понимаю почему, потому что я ничего не настраиваю

  2. Кажется, что он нарушает протокол HTTP, потому что он пытается запросить URL с привязкой внутри:

    Консоль: {"lineNumber": 0, "message": "The FetchEvent for \ "https://test.de/x/#/page\" привело к сетевой ошибке ответ: обещание было отклонено. "," message_level ": 2," sourceIdentifier ": 1," sourceURL ":" "}`

Чем fetch () отличается от обработки извлечения по умолчанию в браузере и являются ли эти различия причиной этих ошибок?

Дополнительная информация и код:

Мое приложение также использует старый добрый appCache параллельно с сервисным работником (для обратной совместимости). Я не уверен, что appcache мешает установке сервисного работника при начальной загрузке страницы. Остальная часть кода довольно проста:

Мой index.html в https://test.de/x/#/page использует appcache и base-href: 

<html manifest="appcache" lang="de">
<head>
   <base href="/x/"/>
</head>
...

Регистрация работника сервиса в теле скрипта 

window.addEventListener('load', {
  navigator.serviceWorker.register('/x/sw.js')
});

Установить и активировать событие 

let MY_CACHE_ID = 'myCache_v1';
let urlsToCache = ['js/main.js'];
self.addEventListener('install', function (event) {
  event.waitUntil(
    caches.open(MY_CACHE_ID)
      .then(function (cache) {        
        return cache.addAll(
          urlsToCache.map(url => new Request(url, 
          {credentials:'include'}))
        )
      })
  );
});

self.addEventListener('activate', function (event) {
  //delete old caches
  let cacheWhitelist = [MY_CACHE_ID];
  event.waitUntil(
    caches.keys().then(function (cacheNames) {
      return Promise.all(
        cacheNames.map(function (cacheName) {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

1 Ответ

0 голосов
/ 27 апреля 2018

fetch(event.request) должно быть действительно близко к значению по умолчанию. (Вы можете получить фактическое значение по умолчанию, вообще не вызывая respondWith(). В большинстве случаев оно не должно наблюдаться, но с CSP и некоторыми битами реферера.)

Учитывая это, я не уверен, как вы заканчиваете с 1. Это не должно быть возможно. К сожалению, вы не дали достаточно информации для отладки происходящего.

Что касается 2, он передает фрагмент сервисному работнику, но он не будет включен в возможный сетевой запрос. Это совпадает с тем, как определяется Fetch, и делается таким образом, чтобы дать работнику сервиса немного дополнительного контекста, который иногда может быть полезен.

...