как использовать Service Worker для кеширования междоменных ресурсов, если ответ 404?

w3:

6.2 Ресурсы между источниками и приложения CORS¶
обычно кэшируют элементы, поступающие из CDN или другого источника. Многие из них можно запросить напрямую, используя элементы <script>, <img>, <video> и <link>. Было бы чрезвычайно ограничено, если бы такого рода совместная работа во время выполнения прервалась в автономном режиме. Точно так же можно использовать XHR для многих видов ресурсов вне источника, если установлены соответствующие заголовки CORS.

ServiceWorkers обеспечивает это, позволяя кэшам извлекать и кэшировать элементы из других источников. Однако действуют некоторые ограничения. Во-первых, в отличие от ресурсов того же происхождения, которые управляются в кэше как объекты ответа с атрибутом типа, установленным на «базовый», сохраненные объекты являются объектами ответа с атрибутом типа, установленным на «непрозрачный». Ответы с типом «непрозрачный» предоставляют гораздо менее выразительный API, чем ответы с типом «базовый»; тела и заголовки не могут быть прочитаны или установлены, равно как и многие другие аспекты их содержимого не могут быть проверены. Их можно передать методу event.respondWith (r) таким же образом, как и Responses с типом "basic", но они не могут быть осмысленно созданы программно. Эти ограничения необходимы для сохранения инвариантов безопасности платформы. Разрешение кешам хранить их позволяет приложениям в большинстве случаев избегать повторной архитектуры.

Я установил заголовок CORS, например:

Access-Control-Allow-Origin:https://xxx.xx.x.com
Access-Control-Allow-Credentials:true

но я все равно получаю «непрозрачный» ответ, и я не могу гарантировать, что код равен 200. Если я кэширую эти неудачные ответы, это вызовет некоторые проблемы.

Например, чум сети вызывает 404-й ответ на междоменные ресурсы, и я кэширую его, тогда я всегда буду использовать этот ответ 404-го кеша, даже если проблема с сетью будет исправлена. Ресурсы с одинаковым происхождением не имеют этой проблемы.


person abu    schedule 25.02.2016    source источник


Ответы (2)


mode в Request (предположительно) по умолчанию "no-cors". (Я говорю «предположительно», потому что считаю, что видел ситуации, в которых неявно созданный Request, используемый в fetch(), приводит к Response с поддержкой CORS.)

Таким образом, вы должны явно указать на использование CORS, если знаете, что ваш сервер его поддерживает:

var corsRequest = new Request(url, {mode: 'cors'});
fetch(corsRequest).then(response => ...); // response won't be opaque.

При правильно настроенном удаленном сервере Request с поддержкой CORS приведет к Response, имеющему type из "cors". В отличие от "opaque" Response, "cors" Response будет открывать лежащие в основе status, body и т. Д.

person Jeff Posnick    schedule 25.02.2016
comment
waoooooooooooooo ~~~~ Большое спасибо !!! Это действительно работает для меня. муа ~~ - person abu; 26.02.2016
comment
Вопрос в том, как вы изначально выполняете запросы, которые туннелируются через сервис-воркер. Если они используют без коров, вы получите именно это. new Request("x").mode однако возвращает корс. - person Anne; 29.02.2016

К сожалению, обнаружить это невозможно.

По соображениям безопасности это явно запрещено: https://github.com/whatwg/fetch/issues/14.

person Marco Castelluccio    schedule 25.02.2016