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