Revision 1ea4f53a5b0fe9705b1ed279a3904ab173e98393 authored by Rimas on 22 February 2017, 17:53:27 UTC, committed by Domenic Denicola on 22 February 2017, 17:53:27 UTC
Fixes two test cases where the "failure" value was the string "true" instead of the boolean.
1 parent 9b41b6d
stub-5.2-cross-origin-resources.html
<!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>
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...