blob: 3a10c9e08838e177b4a3b4cd93b99996c9c74dbd [file] [log] [blame]
<!DOCTYPE html>
<title>Service Workers: Cross-Origin Resources &amp; CORS</title>
<link rel="help" href="">
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
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.
test(function() {
// not_implemented();
}, "There are no tests for section Cross-Origin Resources &amp; CORS so far.");