Revision 6668ff3716086d3f8efead0f5db2d8d2864c3563 authored by Robert Ma on 21 March 2018, 17:35:46 UTC, committed by Robert Ma on 21 March 2018, 17:35:46 UTC
1. Check the HTTP port of wptserve instead of HTTPS to avoid the
   unnecessary complexities of setting up SSL context (which may fail in
   some environments).
2. Use exponential backoff when waiting for wptserve and specify a
   maximum retry to avoid indefinite hang.
3. Use `terminate` instead of `kill` to give wptserve a chance to clean
   up, which is especially useful when running locally.
1 parent dbb38a6
Raw File
stub-4.6.1-cache-lifetimes.html
<!DOCTYPE html>
<html>
<title>Service Workers: Understanding Cache Lifetimes</title>
    <head>
        <link rel="help" href="https://w3c.github.io/ServiceWorker/#cache-lifetimes">
        <script src="/resources/testharness.js"></script>
        <script src="/resources/testharnessreport.js"></script>

    </head>
    <body>

<!--

The `[Cache][1]` instances are not part of the browser's HTTP cache. The
`[Cache][1]` objects are exactly what authors have to manage themselves. The
`[Cache][1]` objects do not get updated unless authors explicitly request them
to be. The `[Cache][1]` objects do not expire unless authors delete the
entries. The `[Cache][1]` objects do not disappear just because the Service
Worker script is updated. That is, caches are not updated automatically.
Updates must be manually managed. This implies that authors should version
their caches by name and make sure to use the caches only from the version of
the ServiceWorker that can safely operate on.

[1]: #cache-interface

-->



    <script>
        test(function() {
            // not_implemented();
        }, "There are no tests for section Understanding Cache Lifetimes so far.");
    </script>

    </body>
</html>

back to top