<!DOCTYPE html>
<html>
<title>Service Workers: Cross-Origin Resources &amp; 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 &amp; CORS so far.");
    </script>

    </body>
</html>