Service worker что это
Кто ты такой, Service Worker?
Service Worker: Я программируемый сетевой проксификатор.
Service Worker звучит круто, но я не очень то понимаю что это
В июле 2015 я участвовала в конференции по JavaScript, проходившей в городе Остин, штат Техас. На сцене — Джейк Арчибальд, которого тогда я знала как забавного британского парня, любителя пошутить на “туалетную тему” 🚽. Уже потом я поняла, что он вполне себе “важный чувак” и является одним из разработчиков спецификации Service Worker’ов.
И вот по ходу истории об UX-откровении, настигнувшем его в общественном туалете, Джейк рассказал залу о новой штуке, названной Service Worker. Штуке, позволяющей вашему веб-сайту вести себя как нативное приложение (по крайней мере тогда я поняла его именно так).
То, о чем он говорил, звучало невероятно, и мне захотелось попробовать технологию на своем проекте. Сначала было немного трудно понять что это… Это не библиотека, не новый HTML элемент и даже не новый JavaScript синтаксис, а такие термины как “кэш” или “прокси” всегда приводили меня в замешательство. Пытаясь разобраться в принципах работы Service Worker’а, я делала пометки на бумаге, и мне в голову пришла идея сравнить его с “пришельцем, которого вы приглашаете пожить в вашем браузере”. Звучит странно? Тогда давайте попробуем разобраться.
S ervice Worker — пришелец во вселенной веб-браузера.
Представьте: ваш браузер — это планета (наподобие Земли), частица большой галактики вашего компьютера. Люди на этой планете разговаривают на своих языках, таких как HTML, CSS и JavaScript, благодаря которым они формируют сообщества — веб страницы.
И если вы веб-разработчик, вы должны хорошо разбираться как функционируют эти сообщества: начиная от их разнообразных элементов и DOM дерева и заканчивая режимами обновления данных на вашем сайте.
На этой планете (в браузере) был придуман способ общения с внешним миром, который позволил запрашивать информацию из других галактик (серверов). Его назвали Hyper Text Transfer Protocol. Именно так ваша планета-браузер превратилась в копилку милых картинок с котятами и ненужных твитов. И именно так она смогла привлечь к себе миллионы постоянных пользователей.
HTTP похож на невероятную волшебную вещицу, однако, чтобы она работала, вам нужен Интернет. Представим его как длинный многоколенчатый трубопровод. Интернет обеспечивает нам необходимое сообщение с удаленными серверами-галактиками. Длина такого трубопровода зависит от того, сколько вы платите обслуживающей организации (интернет-провайдеру), и от качества инфраструктуры в вашем регионе. Если ваша труба узкая или слишком длинная, то и данные из других галактик поступают на вашу планету дольше.
Но дело в том, что Интернет порой оказывается и вовсе недоступным для вашего браузера. В такие периоды ваша планета возвращается в доисторическую эпоху, и никакие из современных вещей вам не доступны, а ваш браузер показывает картинки динозавров, как напоминание о “старых добрых”.
Но подождите! Service Worker уже здесь, чтобы помочь!
Три вещи, которые следует знать о вашем новом приятеле.
Итак, какого типа работу может выполнить для вас Service Worker?
1. Взаимодействие с кэшем
Вы можете попросить Service Worker отслеживать fetch events и сохранять определенные ресурсы в кэше. Позже, когда эти ресурсы понадобятся, он передаст их вашему сайту, а делать внешний HTTP-запрос будет уже не нужно. Таким образом, если необходимые данные предварительно закэшированы, браузер сможет показывать контент веб-страниц даже при отсутствии интернет-подключения.
2. Push-уведомления
Благодаря магии, по которой Service Worker работает даже при выключенном браузере, вы можете всегда быть в курсе, получая push-уведомления.
3. Фоновая синхронизация
Активность при закрытом браузере означает еще и то, что Service Worker будет работать, не отвлекая внимания пользователя на текущие процессы. Скажем, вы используете веб-страницу, будучи offline, но вам необходимо отправить файл. Так вот, Service Worker сам отправит файл на сервер, когда интернет станет доступен снова.
Использование Service Worker для создания ботнета
Если кратко: в этом посте мы рассмотрим один из множества способов запуска бесконечного выполнения кода Javascript в браузере с помощью Service Worker, а еще немного покритикуем саму технологию.
Пример вы найдете по этой ссылке. Закройте вкладку. Через несколько минут откройте DevTools/Application/ServiceWorker/Show All. Видите, код продолжает работать (хотя сейчас это может уже исправлено).
Веб-разработчики такого не ожидали: как тег изображения может запустить выполнение кода JS? Каким образом JS может выполняться непрерывно? Разве так можно?
Service Worker — это слишком сложно
Чтобы повысить популярность «прогрессивных» веб-приложений, команда Chrome создала Service Worker, не спрашивая у вас разрешения. На практике это новое «продвинутое» решение используется только чтобы показывать всплывающее push-уведомление (Конечно, полезность Service Worker-ов на этом не ограничивается, с их помощью реализуются, например, offline-режим и backsync, – прим. переводчика). Если вы не верите мне на слово, откройте свои зарегистрированные Service Worker и изучите их содержимое.
Даже это будет сделать не так-то просто: сотни строк кода, зависимость от FCM и т. д. (FCM = Firebase Cloud Messaging, но его использование не является обязательным в данном случае, – прим. переводчика). Разместите sw.js на сервере, зарегистрируйте worker на стороне клиента, подождите получения Promise, затем выполните serviceWorkerRegistration.pushManager.getSubscription(), запросите конечную точку и registration_id и сохраните их на сервере.
Так реализовал бы я:
По моему скромному мнению, Service Worker — это прекрасный ответ на несуществующий вопрос. Научиться использовать это решение гораздо сложнее, чем Appcache (AppCache, в свою очередь, считается устаревшей технологией со своими минусами, – прим. переводчика ), к тому же оно менее надежно.
Как обеспечить долговременную работу
Service Worker отключается через 60 секунд после того, как получает последнее событие, например, onmessage, onfetch, onforeignfetch и т. д.
1. Отправка сообщений самому себе.
1. Два worker отправляют друг другу запросы ForeignFetch. Чтобы использовать ForeignFetch, вам понадобится получить токен Origin Trial — полностью автоматизированный процесс, который не требует проверки или подтверждения и позволяет злоумышленнику применять новые экспериментальные технологии на реальных пользователях без их согласия.
2. Catworker отправляет cat.gif запрос fetch, в результате регистрируется новый worker с другой областью работы (это называется регистрация по ссылке). Процесс повторяется каждые 55 секунд.
Как это могут использовать злоумышленники?
Прямо сейчас у злоумышленников есть три варианта атаки вашего браузера:
Сейчас этому классу ошибок уделяют недостаточно внимания. Тикеты публичны (1, 2, 3) и получают минимальный приоритет.
Помимо всего этого, подход Origin Trial не безупречен: кто угодно может получить токен, любой может воспользоваться экспериментальной функцией в своих целях. Нужна возможность включать и отключать Service Worker по желанию.
Я убежден, что нужно добавить флажок для отключения Service Worker. Лично мне эта технология пользы не приносит. (Вы читали документацию Cache? Это же как китайская грамота.) Новые функции поступают в эксплуатацию без должной проверки, так что нельзя быть уверенным в Same Origin Policy и других важных концепций безопасности… Вот еще несколько описаний несерьезных уязвимостей: FF, JSONP+XSS=takeover, атака доменов изолированной программной среды (Sandbox).
Как работает JS: сервис-воркеры
Перед вами перевод восьмой части серии материалов об особенностях работы различных механизмов JavaScript. Сегодняшняя статья посвящена сервис-воркерам. Здесь мы рассмотрим их особенности, поговорим об их жизненном цикле, об их поддержке в браузерах, и о сценариях их использования.
Прогрессивные веб-приложения
Прогрессивные веб-приложения, по всей видимости, будут становиться всё популярнее и распространённее. Они нацелены на то, чтобы пользователь воспринимал их не как обычные веб-страницы, а как нечто вроде классических настольных приложений, которые нормально работают независимо от того, подключен компьютер к интернету или нет.
Отсюда исходит одно из основных требований к прогрессивным веб-приложениям, которое заключается в их надёжном функционировании при отсутствующем или нестабильном сетевом соединении. Сервис-воркеры являются важной технической деталью реализации подобного поведения приложений.
Приложение, сервис-воркер, кэш и сетевые ресурсы
Здесь вы можете видеть упрощённую схему взаимоотношений между приложением, сервис-воркером, кэшем, управлением которым занимается сервис-воркер, и сетевыми ресурсами. В идеале, правильная организация взаимодействия приложения с сервис-воркером и кэшем позволит пользователю нормально работать с приложением даже без подключения к сети.
Особенности сервис-воркеров
Если вы хотите как следует изучить сервис-воркеры, вам стоит взглянуть на предыдущий материал этой серии, который посвящён веб-воркерам. В целом можно сказать, что сервис-воркеры — это разновидность веб-воркеров, а если точнее, то они похожи на разделяемые воркеры. В частности, можно выделить следующие важные особенности сервис-воркеров:
Жизненный цикл сервис-воркера
Жизненный цикл сервис-воркера не имеет ничего общего с жизненным циклом веб-страницы. Он включает в себя следующие этапы:
▍Загрузка
▍Установка
Для того чтобы установить сервис-воркер, сначала его нужно зарегистрировать. Это делается в JavaScript-коде. Когда сервис-воркер зарегистрирован, браузеру предлагается запустить установку в фоновом режиме.
Метод register() можно без проблем вызывать каждый раз, когда загружается страница. Браузер самостоятельно выяснит, был ли уже зарегистрирован соответствующий сервис-воркер и правильно обработает повторный запрос на регистрацию.
В ходе процесса установки сервис-воркера рекомендуется загрузить и поместить в кэш статические ресурсы. После их кэширования установка веб-воркера будет успешно завершена. Если загрузка не удастся, автоматически будет сделана попытка повторной установки. В результате, после успешной установки веб-воркера, разработчик может быть уверен в том, что все необходимые статические материалы находятся в кэше.
Почему? Представим, что пользователь впервые открывает веб-приложение. В этот момент сервис-воркер для этого приложения пока не загружен, более того, браузер не может узнать заранее, будет ли приложение использовать сервис-воркер. Если сервис-воркер будет устанавливаться, браузеру понадобится потратить дополнительные системные ресурсы. Эти ресурсы в противном случае пошли бы на рендеринг веб-страницы. Как результат, запуск процесса установки сервис-воркера может отсрочить загрузку и вывод страницы. Обычно же разработчики стремятся к тому, чтобы как можно быстрее показать пользователю рабочую страницу приложения, но в нашем случае без сервис-воркера приложение не сможет нормально работать.
Обратите внимание на то, что вышеприведённые рассуждения имеют смысл только при разговоре о первом посещении страницы. Если, после установки сервис-воркера, пользователь снова посетит ту же страницу, повторная установка производиться не будет, а значит, не пострадает и скорость показа рабочей страницы. После первого посещения страницы приложения сервис-воркер будет активирован, в результате он сможет обрабатывать события загрузки и кэширования при последующих посещениях веб-приложения. Как результат, приложение будет готово к работе в условиях ограниченного сетевого соединения.
▍Активация
После установки сервис-воркера мы переходим к следующему этапу его жизненного цикла — к активации. На этом шаге у разработчика появляется возможность поработать с данными, которые были кэшированы ранее.
После активации сервис-воркер сможет управлять всеми страницами, которые попадают в его область видимости. Тут стоит отметить, что механизмы сервис-воркера не будут действовать на ту страницу, которая его зарегистрировала, до тех пор, пока эта страница не будет перезагружена.
После того, как сервис-воркер получит управление, он может оказаться в одном из следующих состояний:
Жизненный цикл сервис-воркера
Обработка процесса установки внутри сервис-воркера
Сервис-воркер, после того, как был запущен процесс его регистрации, способен воздействовать на происходящее. В частности, речь идёт об обработчике события install в коде сервис-воркера.
Вот что нужно сделать сервис-воркеру при обработке события install :
Если все материалы успешно кэшированы, это означает и успешную установку сервис-воркера. Если что-нибудь загрузить не удастся, тогда установка будет признана несостоявшейся. Поэтому следует обращать особое внимание на то, какие данные требуется поместить в кэш.
Тут надо отметить, что обработка события install внутри сервис-воркера необязательна.
Работа с кэшем в процессе выполнения приложения
Здесь начинается самое интересное. Именно тут мы разберём механизмы перехвата запросов, возврата кэшированных данных и кэширования новых материалов.
Вот что тут, в общих чертах, происходит:
Обновление сервис-воркера
Если имеется хотя бы мельчайшее различие между файлом сервис-воркера, который был загружен, и текущим файлом, браузер решит, что в коде воркера произошли изменения. Это означает, что в приложении должен использоваться новый сервис-воркер.
Зачем всё это нужно? Для того чтобы избежать проблемы наличия двух версий веб-приложения, выполняющихся одновременно, в разных вкладках браузера. Подобное, на самом деле, встречается весьма часто, и ситуация, в которой разные вкладки находятся под контролем разных веб-воркеров, способна привести к серьёзным ошибкам (например — к использованию различных схем данных при локальном хранении информации).
Удаление данных из кэша
При обработке события activate новой версии сервис-воркера, обычно занимаются работой с кэшем. В частности, тут удаляют старые кэши. Если сделать это раньше, на этапе установки нового воркера, старый сервис-воркер не сможет нормально работать.
Вот пример того, как можно удалить из кэша файлы, которые не были помещены в белый список (в данном случае белый список представлен записями page-1 и page-2 ):
Использование HTTPS
Сервис-воркер, который не защищён HTTPS, подвержен атакам посредника, так как злоумышленник сможет перехватывать соединения и создавать фальшивые ответы на запросы приложения. Именно поэтому, для того, чтобы сделать систему безопаснее, разработчик должен регистрировать сервис-воркеры на страницах, которые обслуживаются по HTTPS. В частности, это даёт уверенность в том, что сервис-воркер, загружаемый в браузер, не был модифицирован во время передачи его кода по сети.
Поддержка в браузерах
Пока ситуация с поддержкой сервис-воркеров браузерами не идеальна, но она улучшается:
Поддержка сервис-воркеров в браузерах
Тут можно наблюдать за процессом внедрения поддержки API сервис-воркеров в браузеры.
Сценарии использования
Сервис-воркеры открывают дорогу для замечательных возможностей веб-приложений. Вот некоторые из них:
Итоги
Сервис-воркеры — перспективная технология, являющаяся базой прогрессивных веб-приложений. Эту технологию, а так же её отдельные возможности, поддерживают пока не все браузеры, но у нас есть все основания ожидать улучшения ситуации. Поэтому вполне возможно, что в обозримом будущем таланты сервис-воркеров смогут полноценно раскрыться во всех ведущих браузерах, давая разработчикам новые инструменты и идеи.
Предыдущие части цикла статей:
Уважаемые читатели! Какие сценарии использования сервис-воркеров в ваших проектах кажутся вам наиболее интересными?
Service Workers
В этой статье я хотел бы поговорить о Service Workers (SW). SW позволяют нам сделать наше приложение готовым к работе в автономном режиме, чтобы оно работало, даже если у нас нет подключения к Интернету. Они также позволяют нам использовать множество других расширенных функций, таких как push-уведомления или фоновая синхронизация. SW продолжает работать даже после закрытия браузера, то есть Service Workers продолжают работать. Это фоновый процесс. Итак, давайте зарегистрируем нашего первого Service Worker’a.
(В этой статье я реализую функциональность, связанную с SW, на простом JS, поскольку код написан на простом JS, мы можем интегрировать в любые JS-фреймворки, такие как Angular, React или Vue)
В качестве первого шага добавим файл sw.js в корневую папку проекта. В app.js мы должны проверить, доступен ли SW в навигаторе, то есть поддерживаются ли SW данным браузером. Теперь, когда мы знаем, что SW доступны, мы можем выполнить метод navigator.serviceWorker.register (), указывая путь к файлу, в котором находится наш SW, чтобы его зарегистрировать. Этот метод фактически возвращает Promise. Итак, чтобы получить информацию, как только это будет сделано, мы можем присоединиться к нему.
Поскольку мы зарегистрировали нашего первого SW, давайте добавим наш первый прослушиватель событий. Как я уже сказал, SW работают в фоновом режиме. Но я не упомянул одну вещь, что все они связаны с обработкой событий. Чтобы прикрепить слушателей событий к SW, мы, прежде всего, должны обратиться к нему с помощью ключевого слова self, что в основном означает «предоставь мне доступ к SW», а затем мы можем выполнить метод addEventListener (). SW надают доступ к специальному набору событий, например, к событию установки, которое запускается, когда браузер устанавливает Service Worker’a. Здесь мы выполняем функцию и получаем объект события, который автоматически передается в функцию браузером, и этот объект предоставляет нам информацию о событии установки. Как мы видим, наш Service Worker успешно установлен.
Теперь посмотрим, действительно ли эти файлы загружены в кеш-память.
Выражение event.respondWith () позволяет нам перезаписывать данные, которые отправляются обратно. Вы можете думать о Service Worker’е как о сетевом прокси, по крайней мере, если мы используем здесь событие fetch. Таким образом, каждый исходящий запрос на выборку проходит через Service Worker, как и каждый ответ. То есть, если мы ничего не делаем, ответ просто не передается. Выражение cashes.match () позволяет нам проверить, кэширован ли уже данный запрос. Если это так, он вернет кешированный ответ. Мы не делаем сетевой запрос, мы перехватываем запрос и не выдаем новый, вместо этого мы просто смотрим на то, что мы хотели запросить, и видим, есть ли оно в кеше и если есть, мы возвращаем его обратно. С другой стороны, если мы не находим его в кеше, мы хотим вернуть запрос на выборку там, где мы обращаемся или где мы просто продолжаем исходный запрос, поэтому вертаем fetch (event.request). После всех этих изменений мы наконец можем использовать наше веб-приложение в автономном режиме.
Как видите, наше веб-приложение содержит диаграмму с некоторыми статическими данными, и при нажатии кнопки «ПОЛУЧИТЬ ДАННЫЕ» ничего не происходит. Теперь я хочу сделать так, чтобы нажав эту кнопку, мы получили некоторые статистические данные, отобразили их на диаграмме и сохранили эти данные в кеше. Таким образом, мы реализуем динамическое кеширование. Итак, приступим. Допустим, у нас есть эндпоинт, который возвращает статистические данные о том, сколько пользователей посетили наш сайт. Итак, теперь мы должны взять эти данные и отобразить их на графике.
Как и раньше, я добавлю решение, а затем объясню, как оно работает.
Сначала нам нужно проверить тег события. Затем я использую event.waitUntil (), как и раньше, это просто позволяет мне убедиться, что событие не завершилось преждевременно. Затем мы получаем данные, которые хранятся в indexedDB (используя вспомогательную функцию из utility.js), перебираем их, отправляем post запрос для каждого из сохраняемых фрагментов данных, а затем удаляем их из indexedDB, если мы успешно отправили их на сервер. Вот и все. Давайте теперь попробуем это. Чтобы проверить эту функциональность, мы должны перейти в автономный режим в нашем браузере, нажать кнопку «POST DATA» и затем снова выйти в онлайн.
После нажатия кнопки «POST DATA», когда мы не в сети, ничего не происходит, но когда подключение восстанавливается, мы видим, что синхронизация была выполнена.
И чтобы подтвердить, что данные действительно были отправлены на сервер, нам сначала нужно удалить наш запрос на получение из динамического кеша и нажать кнопку «ПОЛУЧИТЬ ДАННЫЕ».
Некоторые тонкости использования Service Workers
Предисловие
Сервис-воркеры (Service Workers, да простят меня читатели) сегодня являются полезным дополнением к основной функциональности сайта: тут и работа в оффлайне, и фоновая синхронизация данных, и модные пуш-уведомления.
Однако большое количество статей про сервис-воркеры выглядят достаточно сжато и описывают простые примеры. Я попробую обратить внимание на некоторые особенности работы сервис-воркеров, так что требуются какие-то базовые знания. Отправной точкой может быть эта статья (перевод) или чуть более подробная статья.
Несколько сервис-воркеров на одном домене
У регистрации (registration) конкретного сервис-воркера есть такое понятие, как scope. Оно определяет, какие страницы на определённом домене будут подпадать под её контроль. При этом можно регистрировать несколько сервис-воркеров на одном домене, но с разными scope. Если попробовать зарегистрировать их с разными именами, но одним scope, то установленный позднее воркер будет «замещать» своего более раннего брата.
Кстати, для того, чтобы файл по указанному пути можно было установить в качестве сервис-воркера по пути выше (такое поведение запрещено по умолчанию, увеличивать путь можно, уменьшать — нет), то для этого можно использовать http-заголовок Service-Worker-Allowed.
Метод getRegistration() без параметров возвращает подходящую для текущей страницы регистрацию сервис-воркера, возможно, неактивную. Это также значит то, что по вложенному пути мы будем получать ту же самую регистрацию, если нет более подходящей. Это может приводить к неожиданностям, если ожидается работа нескольких сервис-воркеров на одном домене.
Рассмотрим пример: у нас есть установленный сервис-воркер со scope /. Пусть это будет новостной сайт и мы предоставляем оффлайновые версии текстов. Также есть панель управления по пути /admin/ со своим собственным сервис-воркером. Если второй сервис-воркер ещё не попытались установить, то getRegistaration() будет возвращать регистрацию первого сервис-воркера и это может приводить к ошибкам (например, мы будем слать нотификации из панели администратора в сервис-воркер, не готовый к ним вовсе).
getRegistration имеет опциональный параметр — scope. Если его указать, то метод вернёт регистрацию, наиболее подходящую (не обязательно равную) переданному scope. Тем самым мы можем отписываться от сервис-воркеров на вложенных страницах или получать вообще любые регистрации с текущего домена, нужно лишь знать подходящие scope.
А если мы не знаем все scope, то есть метод getRegistrations(), который просто возвращает все регистрации с текущего домена в виде массива. Требуется Firefox или Chrome 45+.
Связь между страницей и сервис-воркером
Возможность обмена данными между сервис-воркером и подчинённой страницей может привести довольно к оригинальным схемам работы. Например, можно сразу присылать данные из кеша, параллельно запрашивая новые; как только будут новые данные — положить их в кеш и прислать на страницу.
Пример на serviceworke.rs показывает простой способ общения с сервис-воркером:
Здесь controller — сервис-воркер, контролирующий страницу. В свежих браузерах (все версии Firefox и Chrome 51+) можно достаточно просто ответить на такой запрос:
В более старых версиях приходилось обходить все вкладки и находить нужную, а то и создавать руками MessageChannel. Также теперь у нас есть возможность отправлять сообщение вкладке из события fetch. Всё это описано в статье, разве что современное апи у нас уже есть.
Другой момент — хранение данных в сервис-воркере. Люди, уже опробовавшие сервис-воркеры, могли заметить, что LocalStorage там нет. Всё потому, что в сервис-воркерах был взят курс на полностью асинхронное апи (за исключением, пожалуй, importScripts). Но внутри всё ещё остаются доступны:
Или как-то так, но тогда нужно будет иметь в одном месте полный список возможных кешей.
Но при всём этом стоит помнить, что никто не гарантирует 100% сохранность данных в хранилищах. Браузер может автоматически чистить CacheStorage и indexedDB при нехватке места на диске, да и пользователь может сделать это сам.
Кроссдоменные запросы и прочее взаимодействие с другими доменами
С введением fetch ситуация могла показаться немного запутанной (там есть разные режимы запроса/ответа), а с сервис-воркерами всё становится в два раза сложнее: один fetch на стороне клиента, второй — на стороне сервис-воркера.
Самое простое понимание, к которому можно придти: «обмануть» CORS и получить доступ к контенту с другого домена без заголовков не получится. Важно разделять два вида использования: с доступом со стороны javascript и без него. Например, подменить одну картинку другой можно без проблем: достаточно указать в fetch сервис-воркера mode: ‘no-cors’ и не важно, какие там заголовки. Если не использовать ‘no-cors’, fetch будет ожидать CORS заголовки и в случае их отсутствия всё окончится ошибкой.
Если говорить более строго, то любой запрос (Request) со страницы имеет mode. Например, запрос картинки — ‘no-cors’, а запрос картинки с атрибутом crossOrigin (anonymous или use-credentials) — уже ‘cors’. Запросы через XMLHttpRequest всегда в режиме ‘cors’. А fetch позволяет задавать режим напрямую.
Ответ (Response) имеет свойство type. Запросы на текущий домен — ‘basic’. Иначе, если режим запроса — ‘cors’, то type ответа тоже будет ‘cors’, при наличии необходимых заголовков. Режим ответа ‘opaque’ можно получить на запрос в режиме ‘no-cors’, в нём нельзя получить доступ к каким-либо данным ответа.
Здесь описаны не все возможные виды режимов запросов, но этого должно быть достаточно для общего понимания. Больше информации можно почерпнуть из статьи с описанием fetch.
Теперь попробуем всё скомбинировать. Со страницы уходит запрос, его перехватывает сервис-воркер и делает свой fetch, получает ответ. До текущего момента ситуация разобрана, но теперь будет нюанс: при передаче ответа с типом ‘opaque’ в ответ на запрос страницы. который был сделан не с режимом ‘no-cors’, мы получим ошибку.
Помимо просто запросов, мы можем установить сервис-воркер на другой домен. Нет, мы не получим контроль за другой страницей через наш сервис-воркер — условия на сервис-воркер остаются теми же (сам скрипт должен быть на том же домене, на который регистрируется воркер). Для этого можно использовать iframe с нужного домена — разрешений от пользователя не требуется и iframe можно сделать просто невидимым.
Другая интересная возможность, которая сейчас находится в своей ранней версии — Foreign Fetch. Если обычный сервис-воркер контролирует запросы со страницы в своём scope (страница в scope, а не запросы), то foreign fetch позволяет контролировать запросы на свой домен. Допустим, обычное событие fetch будет срабатывать при запросе за библиотекой на CDN, а foreignFetch будет срабатывать при всех запросах за этой библиотекой на любых сайтах! Это любопытная возможность может быть использована, например, службами аналитики.
Тестирование
С написанием тестов на сервис-воркеры есть определённые сложности. Составление теста не так просто: если мы хотим проверить оффлайновый режим, то нужно как-то эмулиовать ошибки сети, если хотим проверить обновление — нужно подменять файл новым и тому подобное.
Дополнительные проблемы также состоят в том, что в текущий момент «безголовые» браузеры не поддерживают сервис-воркеры, а значит, нужны настоящие.
Есть стоящая статья на тему тестирования сервис-воркеров. В ней есть ссылки и на пару инструментов: sw-unit-test-sample и platinum-sw (элемент для Polymer, в нём есть также пара тестов). В статье также описан интересный приём: создание ифрейма для того, чтобы он контролировался тестируемым сервис-воркером. Вообще говоря, у элементов iframe и object есть другая особенность: запросы за ними и их содержимым идут в обход текущего сервис-воркера страницы, используя собственные сервис-воркеры.
То, что caches доступно на самой странице, может быть полезно при тестировании для очистки и проверки содержимого кеша.
Важный нюанс при работе автотестов — определение момента, когда сервис-воркер контролирует страницу и может перехватывать запросы. Простой navigator.serviceWorker.ready не всегда является верным решением — ready срабатывает в момент активации сервис воркера, но до того, как закончится выполнение clients.claim(). Более подробно описано здесь, как одно из решений — слушать событие controllerchange.
Обновление сервис-воркера
Есть несколько нюансов при обновлении сервис-воркеров, на которые стоит обратить внимание.
Несмотря на поддержку кеширующих заголовков при запросе скрипта сервис-воркера, браузеры уменьшают время жизни кеша до 24 часов. Сделано это для того, чтобы случайно не оставить сайт у пользователя в убитом состоянии на большой промежуток времени. Вот хороший ответ на StackOverflow про кеширование.
Другой нюанс: обновление срабатывает, только если сам скрипт сервис-воркера обновился, и определение этого происходит побайтово. Из этого следует, что обновление файлов, которые подключены через importScripts, не приведёт к обновлению самого сервис-воркера.
При обновлении часто добавляются в кеш из сети какие-то файлы. Но при этом работает браузерный кеш! Как и при вызовах fetch внутри сервис-воркера. Нужно либо быть уверенным, что файлы не поменялись (например, включать версию/хеш в название файла), либо загружать ресурсы в обход кеша. Чтобы загружать ресурсы в обход кеша, можно или руками звать fetch и потом добавлять ответ в кеш (не забывая проверять response.ok, например), или использовать опцию cache: ‘no-cache’ Request’а (пока работает только в Firefox Nightly). И то и то описано в статье Jake Archibald.
Также стоит упомянуть, что запрос за скриптом сервис-воркера при обновлении идёт в обход обработчика события fetch текущего сервис-воркера.