Любое обходное решение для ошибки перенаправления Chrome M40 для сервисных работников?

Question

У нас есть изображения, которые перенаправляются с нашего медиа-сервера на CDN, который я пытаюсь исключить из моей рабочей рабочей логики, чтобы обойти ошибку в Chrome 40. В Canary один и тот же рабочий может работать нормально. Я думал, что есть event.default(), чтобы вернуться к стандартному поведению, но я не вижу, что в реализации Chrome, и, читая спецификацию, кажется, что нынешняя рекомендация - просто использовать fetch(event.request).

Таким образом, проблема заключается в том, что я должен дождаться, пока 99% всех наших пользователей перейдут на Chrome 41+, чтобы использовать сервис-работников в этом сценарии или есть какой-то способ, которым я могу отказаться некоторые запросы?

Ядро моей логики ниже:

worker.addEventListener('install', function(event){ 
    event.waitUntil(getDefaultCache().then(function(cache){ 
     return cache.addAll(precacheUrls); 
    })); 
}); 

worker.addEventListener('fetch', function(event){ 
    event.respondWith(getDefaultCache().then(function(cache){ 
     return cache.match(event.request).then(function(response){ 
      if (!response){ 
       return fetch(event.request.clone()).then(function(response){ 
        if (cacheablePatterns.some(function(pattern){ 
         return pattern.test(event.request.url); 
        })) { 
         cache.put(event.request, response.clone()); 
        } 

        return response; 
       }); 
      } 

      return response; 
     }); 
    })); 
}); 

Answer 1

После того, как вы внутри event.respondWith() вы должны выдать ответ или вы будете нести ошибки сети. Вы правы, что event.default() в настоящее время не реализовано.

Общее решение - не вводить event.respondWith(), если вы можете синхронно определить, что вы не хотите обрабатывать событие. Основным примером является чем-то вроде:

function fetchHandler(event) { 
    if (event.request.url.indexOf('abc') >= 0) { 
    event.respondWith(abcResponseLogic); 
    } else if (event.request.url.indexOf('def') >= 0) { 
    event.respondWith(defResponseLogic); 
    } 
} 
self.addEventListener('fetch', fetchHandler); 

Если event.respondWith() не вызывается, то этот обработчик fetch является не-оп, а также любые дополнительные зарегистрированные fetch обработчики получить выстрел в запросе. Несколько обработчиков fetch вызываются в том порядке, в котором они добавляются через addEventListener, по одному, до первого звонка event.respondWith(). Если обработчики извлечения не звонят event.respondWith(), тогда пользовательский агент делает запрос точно так, как обычно, если бы не было задействован сервис-работник.

Одна сложная вещь, которую следует учитывать, заключается в том, что определение того, следует ли звонить event.respondWith(), должно выполняться синхронно внутри каждого обработчика fetch. Все, что зависит от асинхронного обещания, не может использоваться для определения того, следует ли звонить event.respondWith(). Если вы попытаетесь сделать что-то асинхронное, а затем вызовите event.respondWith(), вы получите условие гонки и, вероятно, увидите ошибки в консоли рабочего стола о том, как вы не можете ответить на событие, которое уже было обработано.