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