Service Workers Nightly
-Editor’s Draft,
+Editor’s Draft,
- This version:
@@ -2360,12 +2360,6 @@
Set service worker's skip waiting flag.
-- -
If service worker's state is installed, then:
--
-
-
-
Run Activate algorithm passing service worker's registration as the argument.
-
Resolve promise with undefined.
@@ -2898,7 +2892,7 @@Let registration be the result of running Match Service Worker Registration algorithm passing client’s creation URL as the argument.
- -
If registration is not the service worker's containing service worker registration, continue to the next iteration of the loop.
+If registration is not the service worker's containing service worker registration, continue to the next iteration of the loop.
If client’s active service worker is not the service worker, then:
-
@@ -2931,9 +2925,9 @@
An
ExtendableEventobject has an associated extend lifetime promises (an array of promises). It is initially an empty array.An
-ExtendableEventobject has an associated extensions allowed flag. It is initially set.Service workers have two lifecycle events,
+installandactivate. Service workers use theExtendableEventinterface foractivateevent andinstallevent.Service workers have two lifecycle events,
installandactivate. Service workers use theExtendableEventinterface foractivateevent andinstallevent.Service worker extensions that define event handlers may also use or extend the
-ExtendableEventinterface.Note: To extend the lifetime of a service worker, algorithms that dispatch events using the
+ExtendableEventinterface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch, Handle Foreign Fetch, and Handle Functional Event.Note: To extend the lifetime of a service worker, algorithms that dispatch events using the
ExtendableEventinterface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch, Handle Foreign Fetch, and Handle Functional Event.4.4.1.
event.waitUntil(f)
@@ -2951,13 +2945,13 @@waitUntil()method extends the lifetime of the event.Add f to the extend lifetime promises.
Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
-Service workers define the following behaviors for
+installevent andactivateevent, respectively:Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
+Service workers define the following behaviors for
installevent andactivateevent, respectively:-
-
Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
+Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
-
-
Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
+ServiceWorkerGlobalScopeobject that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
ServiceWorkerGlobalScopeobject that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
@@ -3004,7 +2998,7 @@ @@ -3049,7 +3043,7 @@If options.
scopesis empty throw aTypeErrorand abort these steps.- -
Let scopeString be the context object’s relevant global object’s service worker's containing service worker registration’s scope url, serialized.
+Let scopeString be the context object’s relevant global object’s service worker's containing service worker registration’s scope url, serialized.
Let subScopeURLs be an empty list of URLs.
- @@ -3022,9 +3016,9 @@
-
Set this service worker's list of foreign fetch scopes to subScopeURLs.
+Set this service worker's list of foreign fetch scopes to subScopeURLs.
- -
Set this service worker's list of foreign fetch origins to originURLs.
+Set this service worker's list of foreign fetch origins to originURLs.
boolean isReload = false; }; -
Service workers have an essential functional event
+fetch. Forfetchevent, service workers use theFetchEventinterface which extends theExtendableEventinterface.Service workers have an essential functional event
fetch. Forfetchevent, service workers use theFetchEventinterface which extends theExtendableEventinterface.Each event using
FetchEventinterface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:-
@@ -3232,7 +3226,7 @@
sequence
Service workers have a functional event
+foreignfetch. Forforeignfetchevents, service workers use theForeignFetchEventinterface which extends theExtendableEventinterface.Service workers have a functional event
foreignfetch. Forforeignfetchevents, service workers use theForeignFetchEventinterface which extends theExtendableEventinterface.Each event using
ForeignFetchEventinterface has an associated potential response (a response), initially set to null, an associated origin (aUSVStringor null), initially set to null, an associated list of exposed headers (whose element type is a byte string), initially set to an empty list, and the following associated flags that are initially unset:-
@@ -3404,7 +3398,7 @@
sequence<MessagePort> ports = []; }; -
Service workers define the extendable
+messageevent to allow extending the lifetime of the event. For themessageevent, service workers use theExtendableMessageEventinterface which extends theExtendableEventinterface.Service workers define the extendable
messageevent to allow extending the lifetime of the event. For themessageevent, service workers use theExtendableMessageEventinterface which extends theExtendableEventinterface.4.8.1.
event.dataThe data attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to null. It represents the message being sent.
@@ -3439,11 +3433,11 @@installInstallEvent-[Lifecycle event] The service worker's containing service worker registration’s installing worker changes. (See step 11.2 of the Install algorithm.) + [Lifecycle event] The service worker's containing service worker registration’s installing worker changes. (See step 11.2 of the Install algorithm.) activateExtendableEvent-[Lifecycle event] The service worker's containing service worker registration’s active worker changes. (See step 12.2 of the Activate algorithm.) + [Lifecycle event] The service worker's containing service worker registration’s active worker changes. (See step 12.2 of the Activate algorithm.) fetchFetchEvent@@ -3559,7 +3553,7 @@6.2. Understanding Cache Lifetimes
-The
+Cacheinstances are not part of the browser’s HTTP cache. TheCacheobjects are exactly what authors have to manage themselves. TheCacheobjects do not get updated unless authors explicitly request them to be. TheCacheobjects do not expire unless authors delete the entries. TheCacheobjects 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 service worker that can safely operate on.The
Cacheinstances are not part of the browser’s HTTP cache. TheCacheobjects are exactly what authors have to manage themselves. TheCacheobjects do not get updated unless authors explicitly request them to be. TheCacheobjects do not expire unless authors delete the entries. TheCacheobjects 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 service worker that can safely operate on.6.3.
@@ -4251,11 +4245,11 @@self.caches7. Security Considerations
7.1. Secure Context
-Service workers must execute in secure contexts. Service worker clients must also be secure contexts to register a service worker registration, to get access to the service worker registrations and the service workers, to do messaging with the service workers, and to be manipulated by the service workers. This effectively means that service workers and their service worker clients should be hosted over HTTPS. A user agent may allow
+localhost,127.0.0.0/8, and::1/128for development purpose. (Note that they may still be secure contexts.) The primary reason for this restriction is to protect users from the risks associated with insecure contexts.Service workers must execute in secure contexts. Service worker clients must also be secure contexts to register a service worker registration, to get access to the service worker registrations and the service workers, to do messaging with the service workers, and to be manipulated by the service workers. This effectively means that service workers and their service worker clients should be hosted over HTTPS. A user agent may allow
localhost,127.0.0.0/8, and::1/128for development purpose. (Note that they may still be secure contexts.) The primary reason for this restriction is to protect users from the risks associated with insecure contexts.7.2. Content Security Policy
-Whenever a user agent invokes Run Service Worker algorithm with a service worker serviceWorker:
+Whenever a user agent invokes Run Service Worker algorithm with a service worker serviceWorker:
-
If serviceWorker’s script resource was delivered with a
@@ -4269,7 +4263,7 @@Content-Security-PolicyHTTP header containing the value policy, the user agent must enforce policy for serviceWorker.7.3.1. Origin restriction
This section is non-normative.
-A service worker executes in the registering service worker client's origin. One of the advanced concerns that major applications would encounter is whether they can be hosted from a CDN. By definition, these are servers in other places, often on other origins. Therefore, service workers cannot be hosted on CDNs. But they can include resources via importScripts(). The reason for this restriction is that service workers create the opportunity for a bad actor to turn a bad day into a bad eternity.
+A service worker executes in the registering service worker client's origin. One of the advanced concerns that major applications would encounter is whether they can be hosted from a CDN. By definition, these are servers in other places, often on other origins. Therefore, service workers cannot be hosted on CDNs. But they can include resources via importScripts(). The reason for this restriction is that service workers create the opportunity for a bad actor to turn a bad day into a bad eternity.
7.3.2.
@@ -4305,7 +4299,7 @@importScripts(urls)7.4. Cross-Origin Resources and CORS
This section is non-normative.
-Applications tend to cache items that come from a CDN or other origin. 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 fetch many sorts of off-origin resources when appropriate CORS headers are set. Service workers enable this by allowingCachesto fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in theCacheasResponseobjects whose corresponding responses are basic filtered response, the objects stored areResponseobjects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed toevent.respondWith(r)method in the same manner as theResponseobjects whose corresponding responses are basic filtered responses, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. AllowingCachesto store them allows applications to avoid re-architecting in most cases.Applications tend to cache items that come from a CDN or other origin. 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 fetch many sorts of off-origin resources when appropriate CORS headers are set. Service workers enable this by allowingCachesto fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in theCacheasResponseobjects whose corresponding responses are basic filtered response, the objects stored areResponseobjects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed toevent.respondWith(r)method in the same manner as theResponseobjects whose corresponding responses are basic filtered responses, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. AllowingCachesto store them allows applications to avoid re-architecting in most cases.7.5. Implementer Concerns
@@ -4313,19 +4307,19 @@The implementers are encouraged to note:
-
-
Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
+<embed>or<object>) immediately fallback to the network without dispatchingfetchevent.Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
<embed>or<object>) immediately fallback to the network without dispatchingfetchevent. -
-
Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
+Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
7.6. Privacy
-Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request to response map and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages should be cleared when users intend to clear them and should maintain and interoperate with existing user controls e.g. purging all existing persistent storages.
+Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request to response map and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages should be cleared when users intend to clear them and should maintain and interoperate with existing user controls e.g. purging all existing persistent storages.
8. Extensibility
-Service workers are extensible from other specifications.
+Service workers are extensible from other specifications.
8.1. Define API bound to Service Worker Registration
Specifications may define an API tied to a service worker registration by using partial interface definition to the
@@ -4356,7 +4350,7 @@ServiceWorkerRegistrationinterface where it may define the specification specific attributes and methods:8.4. Request Functional Event Dispatch
-To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
+To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
ServiceWorkerGlobalScopeobject) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.Note: See an example hook defined in Notifications API.
Else:
-
-
Let worker be a new service worker.
+Let worker be a new service worker.
-
Generate a unique opaque string and set worker’s id to the value.
-
@@ -4879,7 +4873,7 @@
job, a job
- -
worker, a service worker
+worker, a service worker
registration, a service worker registration
- @@ -4903,7 +4897,7 @@
Invoke Resolve Job Promise with job and the
ServiceWorkerRegistrationobject which represents registration.- -
Queue a task to fire an event named
+updatefoundat all theServiceWorkerRegistrationobjects for all the service worker clients whose creation URL matches registration’s scope url and all the service workers whose containing service worker registration is registration.Queue a task to fire an event named
updatefoundat all theServiceWorkerRegistrationobjects for all the service worker clients whose creation URL matches registration’s scope url and all the service workers whose containing service worker registration is registration.Let installingWorker be registration’s installing worker.
- @@ -4968,21 +4962,13 @@
If redundantWorker is not null, run the Update Worker State algorithm passing redundantWorker and redundant as the arguments.
- -
If registration’s waiting worker’s skip waiting flag is set, then:
--
-
-
-
Run Activate algorithm passing registration as the argument.
- -
-
Invoke Finish Job with job and abort these steps.
-
- -
Invoke Finish Job with job.
+Invoke Finish Job with job.
Wait for all the tasks queued by Update Worker State invoked in this algorithm have executed.
- -
Wait until no service worker client is using registration or registration’s waiting worker’s skip waiting flag is set.
+Wait until no service worker client is using registration or registration’s waiting worker’s skip waiting flag is set.
- -
If registration’s waiting worker waitingWorker is not null and waitingWorker’s skip waiting flag is not set, invoke Activate algorithm with registration as its argument.
+If registration’s waiting worker is not null, invoke Activate algorithm with registration as its argument.
- -
@@ -4999,7 +4985,7 @@ -
-
If registration’s waiting worker is null, abort these steps.
+If registration’s waiting worker is null, abort these steps.
-
Let redundantWorker be null.
-
@@ -5013,7 +4999,7 @@
Terminate redundantWorker.
- -
Run the Update Registration State algorithm passing registration, "
+active" and registration’s waiting worker as the arguments.Run the Update Registration State algorithm passing registration, "
active" and registration’s waiting worker as the arguments.Run the Update Registration State algorithm passing registration, "
waiting" and null as the arguments.- @@ -5070,7 +5056,7 @@
Input
- -
serviceWorker, a service worker
+serviceWorker, a service worker
Output
- @@ -5148,7 +5134,7 @@
Create a new
WorkerLocationobject and associate it with workerGlobalScope.- -
If serviceWorker is an active worker, and there are any tasks queued in serviceWorker’s containing service worker registration’s task queues, queue them to serviceWorker’s event loop’s task queues in the same order using their original task sources.
+If serviceWorker is an active worker, and there are any tasks queued in serviceWorker’s containing service worker registration’s task queues, queue them to serviceWorker’s event loop’s task queues in the same order using their original task sources.
If script is a classic script, then run the classic script script. Otherwise, it is a module script; run the module script script.
Note: In addition to the usual possibilities of returning a value or failing due to an exception, this could be prematurely aborted by the kill a worker or terminate a worker algorithms.
@@ -5173,7 +5159,7 @@Input
- -
serviceWorker, a service worker
+serviceWorker, a service worker
Output
- @@ -5187,7 +5173,7 @@
Set serviceWorkerGlobalScope’s closing flag to true.
- -
If there are any tasks, whose task source is either the handle fetch task source or the handle functional event task source, queued in serviceWorkerGlobalScope’s event loop’s task queues, queue them to serviceWorker’s containing service worker registration’s corresponding task queues in the same order using their original task sources, and discard all the tasks (including tasks whose task source is neither the handle fetch task source nor the handle functional event task source) from serviceWorkerGlobalScope’s event loop’s task queues without processing them.
+If there are any tasks, whose task source is either the handle fetch task source or the handle functional event task source, queued in serviceWorkerGlobalScope’s event loop’s task queues, queue them to serviceWorker’s containing service worker registration’s corresponding task queues in the same order using their original task sources, and discard all the tasks (including tasks whose task source is neither the handle fetch task source nor the handle functional event task source) from serviceWorkerGlobalScope’s event loop’s task queues without processing them.
Note: This effectively means that the fetch events and the other functional events such as push events are backed up by the registration’s task queues while the other tasks including message events are discarded.
Abort the script currently running in serviceWorker.
@@ -5223,11 +5209,11 @@Unset event’s extensions allowed flag. -
The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
+The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
Handle Fetch
-The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
+The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
-
Input
@@ -5292,12 +5278,12 @@If request’s destination is not
-"report", set reservedClient’s active service worker to registration’s active worker.Note: From this point, the service worker client starts to use its active service worker’s containing service worker registration.
+Note: From this point, the service worker client starts to use its active service worker’s containing service worker registration.
Else if request is a subresource request, then:
-
-
If client’s active service worker is non-null, set registration to client’s active service worker’s containing service worker registration.
+If client’s active service worker is non-null, set registration to client’s active service worker’s containing service worker registration.
-
Else, return null.
Note: To avoid unnecessary delays, the Handle Fetch enforces early return when no event listeners have been deterministically added in the service worker’s global during the very first script execution.
- -
If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
+If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
Invoke Run Service Worker algorithm with activeWorker as the argument.
- @@ -5392,7 +5378,7 @@
Handle Foreign Fetch
-The Handle Foreign Fetch algorithm is the entry point for the fetch handling handed to the service worker context to handle foreign fetch requests.
+The Handle Foreign Fetch algorithm is the entry point for the fetch handling handed to the service worker context to handle foreign fetch requests.
-
Input
@@ -5421,10 +5407,10 @@If activeWorker is null, return null.
- -
If activeWorker’s state is activating, then:
+If activeWorker’s state is activating, then:
If activeWorker’s origin is the same as request’s origin, return null.
@@ -5572,7 +5558,7 @@Note: To avoid unnecessary delays, the Handle Functional Event enforces early return when no event listeners have been deterministically added in the service worker’s global during the very first script execution.
- -
If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
+If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
Invoke Run Service Worker algorithm with activeWorker as the argument.
- @@ -5615,7 +5601,7 @@
If registration’s uninstalling flag is set, invoke Clear Registration algorithm passing registration as its argument and abort these steps.
- -
If registration’s waiting worker is not null, run Activate algorithm with registration as the argument.
+If registration’s waiting worker is not null, run Activate algorithm with registration as the argument.
- -
@@ -5643,10 +5629,10 @@ installing worker to null.
- -
If registration’s waiting worker is not null, run the following substep in parallel:
+If registration’s waiting worker is not null, run the following substep in parallel:
@@ -5670,7 +5656,7 @@Invoke Reject Job Promise with job and a "
SecurityError" exception.- -
Invoke Finish Job with job and abort these steps.
+Invoke Finish Job with job and abort these steps.
Let registration be the result of running Get Registration algorithm passing job’s scope url as the argument.
@@ -5680,7 +5666,7 @@Invoke Resolve Job Promise with job and false.
- -
Invoke Finish Job with job and abort these steps.
+Invoke Finish Job with job and abort these steps.
Set registration’s uninstalling flag.
@@ -5690,7 +5676,7 @@If no service worker client is using registration, invoke Clear Registration algorithm passing registration as its argument.
Note: When the registration is being used for a client, the deletion of the registration is handled by the Handle Service Worker Client Unload algorithm.
- -
Invoke Finish Job with job.
+Invoke Finish Job with job.
@@ -5750,10 +5736,10 @@ Update Worker State algorithm passing redundantWorker and redundant as the arguments.
- -
If registration’s waiting worker is not null, then:
+If registration’s waiting worker is not null, then:
-
-
Set redundantWorker to registration’s waiting worker.
+Set redundantWorker to registration’s waiting worker.
-
Terminate redundantWorker.
-
@@ -5793,7 +5779,7 @@
target, a string (one of "
installing", "waiting", and "active")- -
source, a service worker or null
+source, a service worker or null
Output
- @@ -5818,12 +5804,12 @@
Else if target is "
waiting", then:-
-
Set registration’s waiting worker to source.
+Set registration’s waiting worker to source.
-
For each registrationObject in registrationObjects:
-
-
Queue a task to set the
+waitingattribute of registrationObject to theServiceWorkerobject that represents registration’s waiting worker, or null if registration’s waiting worker is null.Queue a task to set the
waitingattribute of registrationObject to theServiceWorkerobject that represents registration’s waiting worker, or null if registration’s waiting worker is null.
-
-
- @@ -5847,9 +5833,9 @@
Input
- -
worker, a service worker
+worker, a service worker
- -
state, a service worker's state
+state, a service worker's state
Output
- @@ -5857,7 +5843,7 @@
-
-
Set worker’s state to state.
+Set worker’s state to state.
-
Let workerObjects be an array containing all the
ServiceWorkerobjects associated with worker. -
@@ -5867,33 +5853,33 @@
Queue a task to run these substeps: -
-
Set the
+stateattribute of workerObject to the value (inServiceWorkerStateenumeration) corresponding to the first matching statement, switching on worker’s state:Set the
stateattribute of workerObject to the value (inServiceWorkerStateenumeration) corresponding to the first matching statement, switching on worker’s state:-
installing
-
-
Note: The service worker in this state is considered an installing worker. During this state,
+waitUntil()can be called inside theoninstallevent handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.Note: The service worker in this state is considered an installing worker. During this state,
waitUntil()can be called inside theoninstallevent handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated. -
installed
-
-
Note: The service worker in this state is considered a waiting worker.
+Note: The service worker in this state is considered a waiting worker.
-
activating
-
-
Note: The service worker in this state is considered an active worker. During this state,
+waitUntil()can be called inside theonactivateevent handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.Note: The service worker in this state is considered an active worker. During this state,
waitUntil()can be called inside theonactivateevent handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated. -
activated
-
-
Note: The service worker in this state is considered an active worker ready to handle functional events.
+Note: The service worker in this state is considered an active worker ready to handle functional events.
-
redundant
-
-
Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
+Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
-
-
Fire an event named
@@ -5968,7 +5954,7 @@statechangeat workerObject.Output
- -
worker, a service worker
+worker, a service worker
-
@@ -6036,7 +6022,7 @@
Output
- -
newestWorker, a service worker
+newestWorker, a service worker
-
@@ -6046,7 +6032,7 @@
If registration’s installing worker is not null, set newestWorker to registration’s installing worker.
- -
Else if registration’s waiting worker is not null, set newestWorker to registration’s waiting worker.
+Else if registration’s waiting worker is not null, set newestWorker to registration’s waiting worker.
Else if registration’s active worker is not null, set newestWorker to registration’s active worker.
- @@ -6331,18 +6317,18 @@
Appendix B: Extended HTTP headers
Service Worker Script Request
-An HTTP request to fetch a service worker's script resource will include the following header:
+An HTTP request to fetch a service worker's script resource will include the following header:
-
-
Indicates this request is a service worker's script resource request.
+Indicates this request is a service worker's script resource request.
Note: This header helps administrators log the requests and detect threats.
Service Worker Script Response
-An HTTP response to a service worker's script resource request can include the following header:
+An HTTP response to a service worker's script resource request can include the following header:
-
@@ -6389,7 +6375,7 @@
Syntax
-ABNF for the values of the headers used by the service worker's script resource requests and responses:
+ABNF for the values of the headers used by the service worker's script resource requests and responses:
Service-Worker = %x73.63.72.69.70.74 ; "script", case-sensitive
Note: The validation of the Service-Worker-Allowed header’s values is done by URL parsing algorithm (in Update algorithm) instead of using ABNF.
@@ -7508,35 +7494,35 @@3.4.1. controller
- 3.5. Events (2)
- 4.1. ServiceWorkerGlobalScope (2) (3) (4) -
- 4.1.3. skipWaiting() (2) (3) (4) -
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) -
- 4.5.1. event.registerForeignFetch(options) (2) -
- 4.6. FetchEvent (2) -
- 4.7. ForeignFetchEvent (2) -
- 4.8. ExtendableMessageEvent (2) -
- 6.2. Understanding Cache Lifetimes (2) -
- 7.1. Secure Context (2) (3) (4) (5) -
- 7.2. Content Security Policy -
- 7.3.1. Origin restriction (2) (3) -
- 7.4. Cross-Origin Resources and CORS -
- 7.5. Implementer Concerns (2) (3) -
- 7.6. Privacy (2) -
- 8. Extensibility -
- 8.4. Request Functional Event Dispatch -
- Update -
- Install (2) -
- Run Service Worker -
- Terminate Service Worker -
- Extend Service Worker Lifetime -
- Handle Fetch -
- Handle Foreign Fetch -
- Update Registration State -
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) -
- Match Service Worker for Foreign Fetch -
- Get Newest Worker -
- Service Worker Script Request (2) -
- Service Worker Script Response -
- Syntax +
- 4.1.3. skipWaiting() (2) +
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) +
- 4.5.1. event.registerForeignFetch(options) (2) +
- 4.6. FetchEvent (2) +
- 4.7. ForeignFetchEvent (2) +
- 4.8. ExtendableMessageEvent (2) +
- 6.2. Understanding Cache Lifetimes (2) +
- 7.1. Secure Context (2) (3) (4) (5) +
- 7.2. Content Security Policy +
- 7.3.1. Origin restriction (2) (3) +
- 7.4. Cross-Origin Resources and CORS +
- 7.5. Implementer Concerns (2) (3) +
- 7.6. Privacy (2) +
- 8. Extensibility +
- 8.4. Request Functional Event Dispatch +
- Update +
- Install (2) +
- Run Service Worker +
- Terminate Service Worker +
- Extend Service Worker Lifetime +
- Handle Fetch +
- Handle Foreign Fetch +
- Update Registration State +
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) +
- Match Service Worker for Foreign Fetch +
- Get Newest Worker +
- Service Worker Script Request (2) +
- Service Worker Script Response +
- Syntax
installing" and null as the arguments. 1. Run the Update Worker State algorithm passing |registration|'s waiting worker and *installed* as the arguments. 1. If |redundantWorker| is not null, run the Update Worker State algorithm passing |redundantWorker| and *redundant* as the arguments. - 1. If |registration|'s waiting worker's skip waiting flag is set, then: - 1. Run Activate algorithm passing |registration| as the argument. - 1. Invoke Finish Job with |job| and abort these steps. 1. Invoke Finish Job with |job|. 1. Wait for all the tasks queued by Update Worker State invoked in this algorithm have executed. 1. Wait until no [=/service worker client=] is using |registration| or |registration|'s waiting worker's skip waiting flag is set. - 1. If |registration|'s waiting worker |waitingWorker| is not null and |waitingWorker|'s skip waiting flag is not set, invoke Activate algorithm with |registration| as its argument. + 1. If |registration|'s waiting worker is not null, invoke Activate algorithm with |registration| as its argument. - -
- -
- -
-
-
- -
diff --git a/docs/v1/index.html b/docs/v1/index.html index ecbe96d5..ed80c19e 100644 --- a/docs/v1/index.html +++ b/docs/v1/index.html @@ -1424,7 +1424,7 @@ Service Workers 1
-Editor’s Draft,
+Editor’s Draft,
- This version:
@@ -2352,12 +2352,6 @@
Set service worker's skip waiting flag.
-- -
If service worker's state is installed, then:
--
-
-
-
Run Activate algorithm passing service worker's registration as the argument.
-
Resolve promise with undefined.
@@ -2887,7 +2881,7 @@Let registration be the result of running Match Service Worker Registration algorithm passing client’s creation URL as the argument.
- -
If registration is not the service worker's containing service worker registration, continue to the next iteration of the loop.
+If registration is not the service worker's containing service worker registration, continue to the next iteration of the loop.
If client’s active service worker is not the service worker, then:
-
@@ -2920,9 +2914,9 @@
An
ExtendableEventobject has an associated extend lifetime promises (an array of promises). It is initially an empty array.An
-ExtendableEventobject has an associated extensions allowed flag. It is initially set.Service workers have two lifecycle events,
+installandactivate. Service workers use theExtendableEventinterface foractivateevent andinstallevent.Service workers have two lifecycle events,
installandactivate. Service workers use theExtendableEventinterface foractivateevent andinstallevent.Service worker extensions that define event handlers may also use or extend the
-ExtendableEventinterface.Note: To extend the lifetime of a service worker, algorithms that dispatch events using the
+ExtendableEventinterface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch and Handle Functional Event.Note: To extend the lifetime of a service worker, algorithms that dispatch events using the
ExtendableEventinterface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch and Handle Functional Event.4.4.1.
event.waitUntil(f)
@@ -2940,13 +2934,13 @@waitUntil()method extends the lifetime of the event.Add f to the extend lifetime promises.
Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
-Service workers define the following behaviors for
+installevent andactivateevent, respectively:Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
+Service workers define the following behaviors for
installevent andactivateevent, respectively:-
-
Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
+Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
-
-
Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
+ServiceWorkerGlobalScopeobject that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
ServiceWorkerGlobalScopeobject that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
@@ -2970,7 +2964,7 @@ boolean isReload = false; }; -
Service workers have an essential functional event
+fetch. Forfetchevent, service workers use theFetchEventinterface which extends theExtendableEventinterface.Service workers have an essential functional event
fetch. Forfetchevent, service workers use theFetchEventinterface which extends theExtendableEventinterface.Each event using
FetchEventinterface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:-
@@ -3151,7 +3145,7 @@
sequence
Service workers define the extendable
+messageevent to allow extending the lifetime of the event. For themessageevent, service workers use theExtendableMessageEventinterface which extends theExtendableEventinterface.Service workers define the extendable
messageevent to allow extending the lifetime of the event. For themessageevent, service workers use theExtendableMessageEventinterface which extends theExtendableEventinterface.4.6.1.
event.dataThe data attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to null. It represents the message being sent.
@@ -3186,11 +3180,11 @@installExtendableEvent-[Lifecycle event] The service worker's containing service worker registration’s installing worker changes. (See step 11.2 of the Install algorithm.) + [Lifecycle event] The service worker's containing service worker registration’s installing worker changes. (See step 11.2 of the Install algorithm.) activateExtendableEvent-[Lifecycle event] The service worker's containing service worker registration’s active worker changes. (See step 12.2 of the Activate algorithm.) + [Lifecycle event] The service worker's containing service worker registration’s active worker changes. (See step 12.2 of the Activate algorithm.) fetchFetchEvent@@ -3215,7 +3209,7 @@5.2. Understanding Cache Lifetimes
-The
+Cacheinstances are not part of the browser’s HTTP cache. TheCacheobjects are exactly what authors have to manage themselves. TheCacheobjects do not get updated unless authors explicitly request them to be. TheCacheobjects do not expire unless authors delete the entries. TheCacheobjects 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 service worker that can safely operate on.The
Cacheinstances are not part of the browser’s HTTP cache. TheCacheobjects are exactly what authors have to manage themselves. TheCacheobjects do not get updated unless authors explicitly request them to be. TheCacheobjects do not expire unless authors delete the entries. TheCacheobjects 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 service worker that can safely operate on.5.3.
@@ -3907,11 +3901,11 @@self.caches6. Security Considerations
6.1. Secure Context
-Service workers must execute in secure contexts. Service worker clients must also be secure contexts to register a service worker registration, to get access to the service worker registrations and the service workers, to do messaging with the service workers, and to be manipulated by the service workers. This effectively means that service workers and their service worker clients should be hosted over HTTPS. A user agent may allow
+localhost,127.0.0.0/8, and::1/128for development purpose. (Note that they may still be secure contexts.) The primary reason for this restriction is to protect users from the risks associated with insecure contexts.Service workers must execute in secure contexts. Service worker clients must also be secure contexts to register a service worker registration, to get access to the service worker registrations and the service workers, to do messaging with the service workers, and to be manipulated by the service workers. This effectively means that service workers and their service worker clients should be hosted over HTTPS. A user agent may allow
localhost,127.0.0.0/8, and::1/128for development purpose. (Note that they may still be secure contexts.) The primary reason for this restriction is to protect users from the risks associated with insecure contexts.6.2. Content Security Policy
-Whenever a user agent invokes Run Service Worker algorithm with a service worker serviceWorker:
+Whenever a user agent invokes Run Service Worker algorithm with a service worker serviceWorker:
-
If serviceWorker’s script resource was delivered with a
@@ -3925,7 +3919,7 @@Content-Security-PolicyHTTP header containing the value policy, the user agent must enforce policy for serviceWorker.6.3.1. Origin restriction
This section is non-normative.
-A service worker executes in the registering service worker client's origin. One of the advanced concerns that major applications would encounter is whether they can be hosted from a CDN. By definition, these are servers in other places, often on other origins. Therefore, service workers cannot be hosted on CDNs. But they can include resources via importScripts(). The reason for this restriction is that service workers create the opportunity for a bad actor to turn a bad day into a bad eternity.
+A service worker executes in the registering service worker client's origin. One of the advanced concerns that major applications would encounter is whether they can be hosted from a CDN. By definition, these are servers in other places, often on other origins. Therefore, service workers cannot be hosted on CDNs. But they can include resources via importScripts(). The reason for this restriction is that service workers create the opportunity for a bad actor to turn a bad day into a bad eternity.
6.3.2.
@@ -3961,7 +3955,7 @@importScripts(urls)6.4. Cross-Origin Resources and CORS
This section is non-normative.
-Applications tend to cache items that come from a CDN or other origin. 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 fetch many sorts of off-origin resources when appropriate CORS headers are set. Service workers enable this by allowingCachesto fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in theCacheasResponseobjects whose corresponding responses are basic filtered response, the objects stored areResponseobjects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed toevent.respondWith(r)method in the same manner as theResponseobjects whose corresponding responses are basic filtered responses, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. AllowingCachesto store them allows applications to avoid re-architecting in most cases.Applications tend to cache items that come from a CDN or other origin. 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 fetch many sorts of off-origin resources when appropriate CORS headers are set. Service workers enable this by allowingCachesto fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in theCacheasResponseobjects whose corresponding responses are basic filtered response, the objects stored areResponseobjects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed toevent.respondWith(r)method in the same manner as theResponseobjects whose corresponding responses are basic filtered responses, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. AllowingCachesto store them allows applications to avoid re-architecting in most cases.6.5. Implementer Concerns
@@ -3969,19 +3963,19 @@The implementers are encouraged to note:
-
-
Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
+<embed>or<object>) immediately fallback to the network without dispatchingfetchevent.Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
<embed>or<object>) immediately fallback to the network without dispatchingfetchevent. -
-
Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
+Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
6.6. Privacy
-Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request to response map and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages should be cleared when users intend to clear them and should maintain and interoperate with existing user controls e.g. purging all existing persistent storages.
+Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request to response map and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages should be cleared when users intend to clear them and should maintain and interoperate with existing user controls e.g. purging all existing persistent storages.
7. Extensibility
-Service workers are extensible from other specifications.
+Service workers are extensible from other specifications.
7.1. Define API bound to Service Worker Registration
Specifications may define an API tied to a service worker registration by using partial interface definition to the
@@ -4012,7 +4006,7 @@ServiceWorkerRegistrationinterface where it may define the specification specific attributes and methods:7.4. Request Functional Event Dispatch
-To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
+To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
ServiceWorkerGlobalScopeobject) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.Note: See an example hook defined in Notifications API.
Else:
-
-
Let worker be a new service worker.
+Let worker be a new service worker.
-
Generate a unique opaque string and set worker’s id to the value.
-
@@ -4484,7 +4478,7 @@
job, a job
- -
worker, a service worker
+worker, a service worker
registration, a service worker registration
- @@ -4508,7 +4502,7 @@
Invoke Resolve Job Promise with job and the
ServiceWorkerRegistrationobject which represents registration.- -
Queue a task to fire an event named
+updatefoundat all theServiceWorkerRegistrationobjects for all the service worker clients whose creation URL matches registration’s scope url and all the service workers whose containing service worker registration is registration.Queue a task to fire an event named
updatefoundat all theServiceWorkerRegistrationobjects for all the service worker clients whose creation URL matches registration’s scope url and all the service workers whose containing service worker registration is registration.Let installingWorker be registration’s installing worker.
- @@ -4573,21 +4567,13 @@
If redundantWorker is not null, run the Update Worker State algorithm passing redundantWorker and redundant as the arguments.
- -
If registration’s waiting worker’s skip waiting flag is set, then:
--
-
-
-
Run Activate algorithm passing registration as the argument.
- -
-
Invoke Finish Job with job and abort these steps.
-
- -
Invoke Finish Job with job.
+Invoke Finish Job with job.
Wait for all the tasks queued by Update Worker State invoked in this algorithm have executed.
- -
Wait until no service worker client is using registration or registration’s waiting worker’s skip waiting flag is set.
+Wait until no service worker client is using registration or registration’s waiting worker’s skip waiting flag is set.
- -
If registration’s waiting worker waitingWorker is not null and waitingWorker’s skip waiting flag is not set, invoke Activate algorithm with registration as its argument.
+If registration’s waiting worker is not null, invoke Activate algorithm with registration as its argument.
- -
@@ -4604,7 +4590,7 @@ -
-
If registration’s waiting worker is null, abort these steps.
+If registration’s waiting worker is null, abort these steps.
-
Let redundantWorker be null.
-
@@ -4618,7 +4604,7 @@
Terminate redundantWorker.
- -
Run the Update Registration State algorithm passing registration, "
+active" and registration’s waiting worker as the arguments.Run the Update Registration State algorithm passing registration, "
active" and registration’s waiting worker as the arguments.Run the Update Registration State algorithm passing registration, "
waiting" and null as the arguments.- @@ -4675,7 +4661,7 @@
Input
- -
serviceWorker, a service worker
+serviceWorker, a service worker
Output
- @@ -4753,7 +4739,7 @@
Create a new
WorkerLocationobject and associate it with workerGlobalScope.- -
If serviceWorker is an active worker, and there are any tasks queued in serviceWorker’s containing service worker registration’s task queues, queue them to serviceWorker’s event loop’s task queues in the same order using their original task sources.
+If serviceWorker is an active worker, and there are any tasks queued in serviceWorker’s containing service worker registration’s task queues, queue them to serviceWorker’s event loop’s task queues in the same order using their original task sources.
If script is a classic script, then run the classic script script. Otherwise, it is a module script; run the module script script.
Note: In addition to the usual possibilities of returning a value or failing due to an exception, this could be prematurely aborted by the kill a worker or terminate a worker algorithms.
@@ -4778,7 +4764,7 @@Input
- -
serviceWorker, a service worker
+serviceWorker, a service worker
Output
- @@ -4792,7 +4778,7 @@
Set serviceWorkerGlobalScope’s closing flag to true.
- -
If there are any tasks, whose task source is either the handle fetch task source or the handle functional event task source, queued in serviceWorkerGlobalScope’s event loop’s task queues, queue them to serviceWorker’s containing service worker registration’s corresponding task queues in the same order using their original task sources, and discard all the tasks (including tasks whose task source is neither the handle fetch task source nor the handle functional event task source) from serviceWorkerGlobalScope’s event loop’s task queues without processing them.
+If there are any tasks, whose task source is either the handle fetch task source or the handle functional event task source, queued in serviceWorkerGlobalScope’s event loop’s task queues, queue them to serviceWorker’s containing service worker registration’s corresponding task queues in the same order using their original task sources, and discard all the tasks (including tasks whose task source is neither the handle fetch task source nor the handle functional event task source) from serviceWorkerGlobalScope’s event loop’s task queues without processing them.
Note: This effectively means that the fetch events and the other functional events such as push events are backed up by the registration’s task queues while the other tasks including message events are discarded.
Abort the script currently running in serviceWorker.
@@ -4828,11 +4814,11 @@Unset event’s extensions allowed flag. -
The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
+The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
Handle Fetch
-The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
+The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
-
Input
@@ -4897,12 +4883,12 @@If request’s destination is not
-"report", set reservedClient’s active service worker to registration’s active worker.Note: From this point, the service worker client starts to use its active service worker’s containing service worker registration.
+Note: From this point, the service worker client starts to use its active service worker’s containing service worker registration.
Else if request is a subresource request, then:
-
-
If client’s active service worker is non-null, set registration to client’s active service worker’s containing service worker registration.
+If client’s active service worker is non-null, set registration to client’s active service worker’s containing service worker registration.
-
Else, return null.
Note: To avoid unnecessary delays, the Handle Fetch enforces early return when no event listeners have been deterministically added in the service worker’s global during the very first script execution.
- -
If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
+If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
Invoke Run Service Worker algorithm with activeWorker as the argument.
- @@ -5030,7 +5016,7 @@
Note: To avoid unnecessary delays, the Handle Functional Event enforces early return when no event listeners have been deterministically added in the service worker’s global during the very first script execution.
- -
If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
+If activeWorker’s state is activating, wait for activeWorker’s state to become activated.
Invoke Run Service Worker algorithm with activeWorker as the argument.
- @@ -5073,7 +5059,7 @@
If registration’s uninstalling flag is set, invoke Clear Registration algorithm passing registration as its argument and abort these steps.
- -
If registration’s waiting worker is not null, run Activate algorithm with registration as the argument.
+If registration’s waiting worker is not null, run Activate algorithm with registration as the argument.
@@ -5101,10 +5087,10 @@ installing worker to null.
- -
If registration’s waiting worker is not null, run the following substep in parallel:
+If registration’s waiting worker is not null, run the following substep in parallel:
@@ -5128,7 +5114,7 @@Invoke Reject Job Promise with job and a "
SecurityError" exception.- -
Invoke Finish Job with job and abort these steps.
+Invoke Finish Job with job and abort these steps.
Let registration be the result of running Get Registration algorithm passing job’s scope url as the argument.
@@ -5138,7 +5124,7 @@Invoke Resolve Job Promise with job and false.
- -
Invoke Finish Job with job and abort these steps.
+Invoke Finish Job with job and abort these steps.
Set registration’s uninstalling flag.
@@ -5148,7 +5134,7 @@If no service worker client is using registration, invoke Clear Registration algorithm passing registration as its argument.
Note: When the registration is being used for a client, the deletion of the registration is handled by the Handle Service Worker Client Unload algorithm.
- -
Invoke Finish Job with job.
+Invoke Finish Job with job.
@@ -5208,10 +5194,10 @@ Update Worker State algorithm passing redundantWorker and redundant as the arguments.
- -
If registration’s waiting worker is not null, then:
+If registration’s waiting worker is not null, then:
-
-
Set redundantWorker to registration’s waiting worker.
+Set redundantWorker to registration’s waiting worker.
-
Terminate redundantWorker.
-
@@ -5251,7 +5237,7 @@
target, a string (one of "
installing", "waiting", and "active")- -
source, a service worker or null
+source, a service worker or null
Output
- @@ -5276,12 +5262,12 @@
Else if target is "
waiting", then:-
-
Set registration’s waiting worker to source.
+Set registration’s waiting worker to source.
-
For each registrationObject in registrationObjects:
-
-
Queue a task to set the
+waitingattribute of registrationObject to theServiceWorkerobject that represents registration’s waiting worker, or null if registration’s waiting worker is null.Queue a task to set the
waitingattribute of registrationObject to theServiceWorkerobject that represents registration’s waiting worker, or null if registration’s waiting worker is null.
-
-
- @@ -5305,9 +5291,9 @@
Input
- -
worker, a service worker
+worker, a service worker
- -
state, a service worker's state
+state, a service worker's state
Output
- @@ -5315,7 +5301,7 @@
-
-
Set worker’s state to state.
+Set worker’s state to state.
-
Let workerObjects be an array containing all the
ServiceWorkerobjects associated with worker. -
@@ -5325,33 +5311,33 @@
Queue a task to run these substeps: -
-
Set the
+stateattribute of workerObject to the value (inServiceWorkerStateenumeration) corresponding to the first matching statement, switching on worker’s state:Set the
stateattribute of workerObject to the value (inServiceWorkerStateenumeration) corresponding to the first matching statement, switching on worker’s state:-
installing
-
-
Note: The service worker in this state is considered an installing worker. During this state,
+waitUntil()can be called inside theoninstallevent handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.Note: The service worker in this state is considered an installing worker. During this state,
waitUntil()can be called inside theoninstallevent handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated. -
installed
-
-
Note: The service worker in this state is considered a waiting worker.
+Note: The service worker in this state is considered a waiting worker.
-
activating
-
-
Note: The service worker in this state is considered an active worker. During this state,
+waitUntil()can be called inside theonactivateevent handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.Note: The service worker in this state is considered an active worker. During this state,
waitUntil()can be called inside theonactivateevent handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated. -
activated
-
-
Note: The service worker in this state is considered an active worker ready to handle functional events.
+Note: The service worker in this state is considered an active worker ready to handle functional events.
-
redundant
-
-
Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
+Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
-
-
Fire an event named
@@ -5457,7 +5443,7 @@statechangeat workerObject.Output
- -
newestWorker, a service worker
+newestWorker, a service worker
-
@@ -5467,7 +5453,7 @@
If registration’s installing worker is not null, set newestWorker to registration’s installing worker.
- -
Else if registration’s waiting worker is not null, set newestWorker to registration’s waiting worker.
+Else if registration’s waiting worker is not null, set newestWorker to registration’s waiting worker.
Else if registration’s active worker is not null, set newestWorker to registration’s active worker.
- @@ -5752,18 +5738,18 @@
Appendix B: Extended HTTP headers
Service Worker Script Request
-An HTTP request to fetch a service worker's script resource will include the following header:
+An HTTP request to fetch a service worker's script resource will include the following header:
-
-
Indicates this request is a service worker's script resource request.
+Indicates this request is a service worker's script resource request.
Note: This header helps administrators log the requests and detect threats.
Service Worker Script Response
-An HTTP response to a service worker's script resource request can include the following header:
+An HTTP response to a service worker's script resource request can include the following header:
-
@@ -5810,7 +5796,7 @@
Syntax
-ABNF for the values of the headers used by the service worker's script resource requests and responses:
+ABNF for the values of the headers used by the service worker's script resource requests and responses:
Service-Worker = %x73.63.72.69.70.74 ; "script", case-sensitive
Note: The validation of the Service-Worker-Allowed header’s values is done by URL parsing algorithm (in Update algorithm) instead of using ABNF.
@@ -6804,31 +6790,31 @@3.4.1. controller
- 3.5. Events (2)
- 4.1. ServiceWorkerGlobalScope (2) (3) (4) -
- 4.1.3. skipWaiting() (2) (3) (4) -
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) -
- 4.5. FetchEvent (2) -
- 4.6. ExtendableMessageEvent (2) -
- 5.2. Understanding Cache Lifetimes (2) -
- 6.1. Secure Context (2) (3) (4) (5) -
- 6.2. Content Security Policy -
- 6.3.1. Origin restriction (2) (3) -
- 6.4. Cross-Origin Resources and CORS -
- 6.5. Implementer Concerns (2) (3) -
- 6.6. Privacy (2) -
- 7. Extensibility -
- 7.4. Request Functional Event Dispatch -
- Update -
- Install (2) -
- Run Service Worker -
- Terminate Service Worker -
- Extend Service Worker Lifetime -
- Handle Fetch -
- Update Registration State -
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) -
- Get Newest Worker -
- Service Worker Script Request (2) -
- Service Worker Script Response -
- Syntax +
- 4.1.3. skipWaiting() (2) +
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) +
- 4.5. FetchEvent (2) +
- 4.6. ExtendableMessageEvent (2) +
- 5.2. Understanding Cache Lifetimes (2) +
- 6.1. Secure Context (2) (3) (4) (5) +
- 6.2. Content Security Policy +
- 6.3.1. Origin restriction (2) (3) +
- 6.4. Cross-Origin Resources and CORS +
- 6.5. Implementer Concerns (2) (3) +
- 6.6. Privacy (2) +
- 7. Extensibility +
- 7.4. Request Functional Event Dispatch +
- Update +
- Install (2) +
- Run Service Worker +
- Terminate Service Worker +
- Extend Service Worker Lifetime +
- Handle Fetch +
- Update Registration State +
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) +
- Get Newest Worker +
- Service Worker Script Request (2) +
- Service Worker Script Response +
- Syntax
- -
- -
-
-
- -
- -
-
- -