https://github.com/web-platform-tests/wpt
Raw File
Tip revision: 351d25746440b28916e0039b7369a3da4ce3e9a9 authored by plehegar on 21 June 2016, 21:14:03 UTC
Add test for onvisibilitychange
Tip revision: 351d257
stub-5.2-cross-origin-resources.html
<!DOCTYPE html>
<html>
<title>Service Workers: Cross-Origin Resources &amp; CORS</title>
    <head>
        <link rel="help" href="https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#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>

back to top