Подробнее о непрозрачных ответах, о том, почему они представляют собой проблему и как с ними работать в сервис-воркере.

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 г.