Подробнее о непрозрачных ответах, о том, почему они представляют собой проблему и как с ними работать в сервис-воркере.
Progressier автоматически обрабатывает непрозрачные ответы, так что вам не о чем беспокоиться. Но если вам интересно узнать больше о непрозрачных ответах, почему они представляют собой проблему и как с ними работать в сервис-воркере, пожалуйста, продолжайте читать.
Что такое непрозрачный ответ?
Когда веб-сайт запрашивает актив, например. изображение JPG или файл JavaScript, он отправляет запрос на сервер. Затем этот сервер отвечает запрошенным изображением или содержимым JavaScript.
Проблемы начинаются, когда актив размещается в домене, отличном от запрашивающего сайта. Браузеры следуют механизму, который называется Совместное использование ресурсов между источниками (или CORS). Короче говоря, это сильно ограничивает ваши действия с ресурсом, расположенным в другом домене.
Один из способов предотвратить проблемы — добавить владельцу ресурса заголовок access-control-allow-origin: *
к ответу (также работает с вашим конкретным доменом вместо *
). По сути, это говорит браузеру Эй, Chrome, просто позволь любому свободно использовать этот ресурс на своем сайте.
Вот где становится интересно — даже без этого заголовка теги <script>
, <style>
или <img>
все равно смогут запрашивать и использовать эти ресурсы. Но ваш код Javascript или сервис-воркер не смогут читать или иным образом изменять их. Ответы, которые может использовать браузер, но которые вы, как разработчик, не можете использовать, называются непрозрачными ответами.
Итак… в чем проблема с непрозрачными ответами?
Когда сервер отправляет ответ браузеру, он также отправляет HTTP код состояния ответа, который сообщает браузеру, был ли запрос успешным или нет.
Все, что начинается с 2xx
, обычно означает успех. 5xx
означает, что на сервере произошла ошибка. И 4xx
ошибка с запросом.
Для непрозрачных ответов всегда используется код состояния ответа 0
.
Ваш сервис-воркер не может узнать, был ли запрос успешным или привел к ошибке. И поскольку запрос сделан совершенно непрозрачным, он не содержит никаких других подсказок, которые могли бы сказать вам, каким путем он был направлен.
Примечание редактора: я понимаю, почему необходимы непрозрачные ответы, но, честно говоря, понятия не имею, почему «непрозрачный» также должен означать скрытие кода состояния запроса. Если кто-то знает, мне искренне интересно узнать больше о причинах этого выбора.
Проблема в том, что большинство приложений и веб-сайтов получают довольно много непрозрачных ответов. И если вы решите не кэшировать их, эти ресурсы вообще не будут доступны в автономном режиме, когда сеть не сможет отправить успешный ответ.
Подход 1: Подход последней инстанции
Подход, который мы используем в Progressier, состоит в том, чтобы кешировать ресурсы, которые имеют непрозрачные ответы, но использовать их только в крайнем случае — когда в кеше нет других доступных ответов и сеть не может предоставить ответ (потому что этот сервер не работает или например, пользователь не в сети).
В этом случае выбор делается между отображением ошибки (100% вероятность ошибки) и отображением непрозрачного ответа, который мог быть или не быть успешным ответом (неизвестная вероятность ошибки, но по определению менее 100%).
Подход 2: подход без кэширования
Поведение по умолчанию в Workbox — вообще не кэшировать непрозрачные ответы. Это еще один верный подход. Это устраняет описанную выше неопределенность, а также гарантирует, что ресурс НЕ будет доступен в автономном режиме.
В тех случаях, когда вашему внешнему интерфейсу действительно нужно знать, что такое ошибка (а не просто знать, что она есть), этот подход обеспечивает согласованность и может быть лучшей альтернативой.
Распознавание и кэширование непрозрачных ответов
Непрозрачный ответ можно определить по коду состояния в объекте Ответ. Если он содержит response.status === 0
, то вы имеете дело с непрозрачным ответом.
Обратите внимание, что возможности кэширования непрозрачных ответов ограничены. Вам обязательно нужно будет вызвать response.clone() перед помещением в кеш. Если вы этого не сделаете, тело ответа будет использовано, когда вы поместите его в кеш, и произойдет сбой, когда вы также вернете его в качестве ответа на событие fetch.
Иногда Response.clone() недостаточно, например, если вам нужно изменить ответ перед помещением в кеш. Поэтому обычно можно сделать копию заголовков и тела запроса и воссоздать ответ с нуля с помощью конструктора Response.
Ну, с непрозрачными ответами… так нельзя. Конструктор просто не позволяет создавать непрозрачные ответы.
Заключение
При создании конструктора стратегий кэширования Progressier мне было довольно весело разбираться во внутренней работе сервис-воркеров. И непрозрачные ответы определенно были одним из самых ярких моментов! Поначалу их причуды может быть трудно понять, но как только вы поймете, как они себя ведут, справиться с ними станет намного проще.
Если эта статья помогла вам понять что-то о непрозрачных ответах, оставьте комментарий. А если у вас есть какие-либо вопросы, не стесняйтесь обращаться ко мне 💪🎉😜
Первоначально опубликовано на https://dev.to 27 декабря 2021 г.