blob: 42c685b1d5525be8c3ed68a9112b2d546e78bcf6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
<!DOCTYPE html>
<html>
<title>Service Workers: Cross-Origin Resources & CORS</title>
<head>
<link rel="help" href="https://w3c.github.io/ServiceWorker/#cross-origin-resources">
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
</head>
<body>
<!--
Applications tend to cache items that come from a CDN or other domain. 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-domain resources when appropriate CORS headers are set.
ServiceWorkers enable this by allowing `Cache`s to fetch and cache off-origin
items. Some restrictions apply, however. First, unlike same-origin resources
which are managed in the `Cache` as `[Promise][1]`s for `Response` instances,
the objects stored are `[Promise][1]`s for `OpaqueResponse` instances.
`OpaqueResponse` provides a much less expressive API than `Response`; the
bodies and headers cannot be read or set, nor many of the other aspects of
their content inspected. They can be passed to `respondWith()` and
`forwardTo()` in the same manner as `Response`s, but cannot be meaningfully
created programmatically. These limitations are necessary to preserve the
security invariants of the platform. Allowing `Cache`s to store them allows
applications to avoid re-architecting in most cases.
[1]: http://goo.gl/3TobQS
-->
<script>
test(function() {
// not_implemented();
}, "There are no tests for section Cross-Origin Resources & CORS so far.");
</script>
</body>
</html>
|
