如果响应是404,如何使用Service Worker来缓存跨域资源? [英] how to use Service Worker to cache cross domain resources if the response is 404?

查看:740
本文介绍了如果响应是404,如何使用Service Worker来缓存跨域资源?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

w3:


6.2跨源资源和CORS¶

应用程序倾向于缓存来自的项目CDN或其他来源。
可以使用< script>,< img>,< video>
和<$ c $直接请求其中许多c>< link> 元素。如果这种运行时
协作在离线时破坏,那将是非常有限的。
同样,当设置
适当的CORS头时,XHR可能有多种非原始资源。

6.2 Cross-Origin Resources and CORS¶
Applications tend to cache items that come from a CDN or other origin. It is possible to request many of them directly using <script>, <img>, <video> and <link> elements. It would be hugely limiting if this sort of runtime collaboration broke when offline. Similarly, it is possible to XHR many sorts of off-origin resources when appropriate CORS headers are set.

ServiceWorkers通过允许缓存启用此功能获取和缓存off-origin
项目。但是,有一些限制。首先,与在Cache中作为Response对象管理的同源资源
不同,类型属性设置为
为basic,存储的对象是类型属性设置为
到的Response对象不透明。类型为opaque的响应提供了比
响应类型基本更低的表达API;无法读取或设置主体和标题,也未检查其内容的其他方面的许多
。它们可以以与响应类型为基本,
相同的方式传递给
event.respondWith(r)方法,但不能以编程方式有意义地创建。这些限制是保存平台安全不变量所必需的
。允许缓存
存储它们允许应用程序在大多数情况下避免重新架构。

ServiceWorkers enable this by allowing Caches to fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the Cache as Response objects with the type attribute set to "basic", the objects stored are Response objects with the type attribute set to "opaque". Responses typed "opaque" provide a much less expressive API than Responses typed "basic"; the bodies and headers cannot be read or set, nor many of the other aspects of their content inspected. They can be passed to event.respondWith(r) method in the same manner as the Responses typed "basic", but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. Allowing Caches to store them allows applications to avoid re-architecting in most cases.

我已将CORS标头设置为:

I have set the CORS header like:

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

但我仍然得到不透明的回复,我无法确保代码是200.
如果我缓存这些不成功的响应,它将导致一些问题。

but I still get an "opaque" response and I cannot ensure the code is 200. If I cache these unsuccessful responses, it will cause some problem.

例如,一个网络密码导致404到跨域资源,
和我缓存它,然后当
网络问题得到纠正时,我总是会使用这个404缓存响应。同源资源没有这个问题。

For example, a chum of network causes a 404 to the cross domain resources, and I cache it, then I will always use this 404 cache response even thongth when the network problem is corrected. The same-origin resource do not have this problem.

推荐答案

模式 请求(据称)默认为no-cors 。 (我说据说因为我相信我已经看到在 fetch()中使用隐式创建的 Request 的情况导致启用CORS的响应。)

The mode of a Request (allegedly) defaults to "no-cors". (I say "allegedly" because I believe I've seen situations in which an implicitly created Request used in fetch() results in a CORS-enabled Response.)

所以你应该明确选择加入CORS如果你知道你的服务器支持它:

So you should be explicit about opting in to CORS if you know that your server supports it:

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

给定正确配置的远程服务器,启用CORS的请求将导致<$ href =https://fetch.spec.whatwg.org/#concept-response-type的响应 =noreferrer> 键入 cors 。与opaque 响应不同,cors 响应将公开基础状态正文等。

Given a properly configured remote server, a CORS-enabled Request will result in a Response that has a type of "cors". Unlike an "opaque" Response, a "cors" Response will expose the underlying status, body, etc.

这篇关于如果响应是404,如何使用Service Worker来缓存跨域资源?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆