Убедитесь, что ваш сервисный работник знает, что делать, когда запрашивается частичный ответ.
Некоторые HTTP-запросы содержат заголовок Range: указывающий, что должна быть возвращена только часть полного ресурса. Они обычно используются для потоковой передачи аудио- или видеоконтента, чтобы обеспечить загрузку небольших фрагментов мультимедиа по требованию вместо того, чтобы запрашивать весь удаленный файл сразу.
Сервис-воркер — это код JavaScript, который находится между вашим веб-приложением и сетью, потенциально перехватывая исходящие сетевые запросы и генерируя на них ответы.
Исторически сложилось так, что запросы диапазона и сервисные работники не очень хорошо взаимодействовали друг с другом. Было необходимо принять специальные меры, чтобы избежать плохих результатов для вашего сервис-воркера. К счастью, ситуация начинает меняться. В браузерах, демонстрирующих правильное поведение, запросы диапазона будут «просто работать» при прохождении через сервис-воркера.
В чем проблема?
Рассмотрим сервис-воркера со следующим прослушивателем событий fetch , который принимает каждый входящий запрос и передает его в сеть:
self.addEventListener('fetch', (event) => {
// The Range: header will not pass through in
// browsers that behave incorrectly.
event.respondWith(fetch(event.request));
});
В браузерах с неправильным поведением, если event.request включал заголовок Range: этот заголовок автоматически удалялся. Запрос, полученный удаленным сервером, вообще не будет включать Range: Это не обязательно «сломит» что-либо, поскольку технически серверу разрешено возвращать полное тело ответа с кодом состояния 200 , даже если в исходном запросе присутствует заголовок Range: Но это приведет к передаче большего количества данных, чем это строго необходимо с точки зрения браузера.
Разработчики, которые знали об этом поведении, могли обойти это, явно проверив наличие заголовка Range: и не вызывая event.respondWith() , если он присутствует. При этом сервис-воркер фактически удаляет себя из картины формирования ответа и вместо этого используется сетевая логика браузера по умолчанию, которая знает, как сохранять запросы диапазона.
self.addEventListener('fetch', (event) => {
// Return without calling event.respondWith()
// if this is a range request.
if (event.request.headers.has('range')) {
return;
}
event.respondWith(fetch(event.request));
});
Однако можно с уверенностью сказать, что большинство разработчиков не осознавали необходимости этого. И было непонятно , зачем это нужно. В конечном счете, это ограничение было связано с тем, что браузерам нужно было успевать за изменениями в базовой спецификации , которая добавляла поддержку этой функциональности.
Что исправлено?
Браузеры, которые ведут себя правильно, сохраняют заголовок Range: при передаче event.request в fetch() . Это означает, что код сервисного работника в моем первоначальном примере позволит удаленному серверу видеть заголовок Range: если он был установлен браузером:
self.addEventListener('fetch', (event) => {
// The Range: header will pass through in browsers
// that behave correctly.
event.respondWith(fetch(event.request));
});
Сервер теперь получает возможность правильно обработать запрос диапазона и вернуть частичный ответ с кодом состояния 206 .
Какие браузеры ведут себя корректно?
Последние версии Safari имеют правильную функциональность . Chrome и Edge, начиная с версии 87 , также ведут себя корректно.
По состоянию на октябрь 2020 года Firefox еще не исправил это поведение, поэтому вам все равно придется учитывать его при развертывании кода вашего сервис-воркера в рабочей среде.
Проверка строки «Включить заголовок диапазона в сетевой запрос» на панели инструментов «Тесты веб-платформы» — лучший способ проверить, исправил ли данный браузер это поведение.
А как насчет обслуживания запросов диапазона из кеша?
Сервисные работники могут сделать гораздо больше, чем просто передать запрос в сеть. Распространенным вариантом использования является добавление ресурсов, таких как аудио- и видеофайлы, в локальный кеш . Затем сервис-воркер может выполнять запросы из этого кеша, полностью минуя сеть.
Все браузеры, включая Firefox, поддерживают проверку запроса внутри обработчика fetch , проверку наличия заголовка Range: а затем локальное выполнение запроса с ответом 206 , поступающим из кеша. Однако код сервисного работника для правильного анализа заголовка Range: и возврата только соответствующего сегмента полного кэшированного ответа не является тривиальным.
К счастью, разработчики, которым нужна помощь, могут обратиться к Workbox , который представляет собой набор библиотек, упрощающий общие сценарии использования сервис-воркеров. workbox-range-request module реализует всю логику, необходимую для обслуживания частичных ответов непосредственно из кеша. Полный рецепт этого варианта использования можно найти в документации Workbox .
Изображение героя в этом посте создано Натали Реей Риггс на Unsplash.