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.
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.
@@ -2912,7 +2906,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:
An ExtendableEvent object has an associated extend lifetime promises (an array of promises). It is initially an empty array.
An ExtendableEvent object has an associated extensions allowed flag. It is initially set.
Service workers have two lifecycle events, install and activate. Service workers use the ExtendableEvent interface for activate event and install event.
Service workers have two lifecycle events, install and activate. Service workers use the ExtendableEvent interface for activate event and install event.
Service worker extensions that define event handlers may also use or extend the ExtendableEvent interface.
Note: To extend the lifetime of a service worker, algorithms that dispatch events using the ExtendableEvent interface 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 ExtendableEvent interface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch, Handle Foreign Fetch, and Handle Functional Event.
event.waitUntil(f)waitUntil() method extends the lifetime of the event.
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 install event and activate event, 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 install event and activate event, 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 ServiceWorkerGlobalScope object 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 ServiceWorkerGlobalScope object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
If options.scopes is empty throw a TypeError and 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.
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.
Service workers have an essential functional event fetch. For fetch event, service workers use the FetchEvent interface which extends the ExtendableEvent interface.
Service workers have an essential functional event fetch. For fetch event, service workers use the FetchEvent interface which extends the ExtendableEvent interface.
Each event using FetchEvent interface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:
Service workers have a functional event foreignfetch. For foreignfetch events, service workers use the ForeignFetchEvent interface which extends the ExtendableEvent interface.
Service workers have a functional event foreignfetch. For foreignfetch events, service workers use the ForeignFetchEvent interface which extends the ExtendableEvent interface.
Each event using ForeignFetchEvent interface has an associated potential response (a response), initially set to null, an associated origin (a USVString or 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:
Service workers define the extendable message event to allow extending the lifetime of the event. For the message event, service workers use the ExtendableMessageEvent interface which extends the ExtendableEvent interface.
Service workers define the extendable message event to allow extending the lifetime of the event. For the message event, service workers use the ExtendableMessageEvent interface which extends the ExtendableEvent interface.
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.
@@ -3453,11 +3447,11 @@install
InstallEvent
- activate
ExtendableEvent
- fetch
FetchEvent
@@ -3573,7 +3567,7 @@ The Cache instances are not part of the browser’s HTTP cache. The Cache objects are exactly what authors have to manage themselves. The Cache objects do not get updated unless authors explicitly request them to be. The Cache objects do not expire unless authors delete the entries. The Cache 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 service worker that can safely operate on.
The Cache instances are not part of the browser’s HTTP cache. The Cache objects are exactly what authors have to manage themselves. The Cache objects do not get updated unless authors explicitly request them to be. The Cache objects do not expire unless authors delete the entries. The Cache 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 service worker that can safely operate on.
self.cachesService 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/128 for 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/128 for 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.
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 Content-Security-Policy HTTP header containing the value policy, the user agent must enforce policy for serviceWorker.
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.
importScripts(urls)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 allowing Caches to fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the Cache as Response objects whose corresponding responses are basic filtered response, the objects stored are Response objects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed to event.respondWith(r) method in the same manner as the Response objects 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. Allowing Caches to 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 allowing Caches to fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the Cache as Response objects whose corresponding responses are basic filtered response, the objects stored are Response objects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed to event.respondWith(r) method in the same manner as the Response objects 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. Allowing Caches to store them allows applications to avoid re-architecting in most cases.
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 dispatching fetch event.
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 dispatching fetch event.
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.
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.
Service workers are extensible from other specifications.
+Service workers are extensible from other specifications.
Specifications may define an API tied to a service worker registration by using partial interface definition to the ServiceWorkerRegistration interface where it may define the specification specific attributes and methods:
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 ServiceWorkerGlobalScope object) 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.
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.
job, a job
worker, a service worker
+worker, a service worker
registration, a service worker registration
Invoke Resolve Job Promise with job and the ServiceWorkerRegistration object which represents registration.
Queue a task to fire an event named updatefound at all the ServiceWorkerRegistration objects 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 updatefound at all the ServiceWorkerRegistration objects 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.
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.
If registration’s waiting worker is null, abort these steps.
+If registration’s waiting worker is null, abort these steps.
Let redundantWorker be null.
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.
Input
serviceWorker, a service worker
+serviceWorker, a service worker
Output
Create a new WorkerLocation object 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.
@@ -5187,7 +5173,7 @@Input
serviceWorker, a service worker
+serviceWorker, a service worker
Output
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.
@@ -5237,11 +5223,11 @@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.
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
@@ -5306,12 +5292,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.
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.
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
@@ -5435,10 +5421,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.
@@ -5586,7 +5572,7 @@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.
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.
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:
@@ -5684,7 +5670,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.
@@ -5694,7 +5680,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.
@@ -5704,7 +5690,7 @@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.
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.
target, a string (one of "installing", "waiting", and "active")
source, a service worker or null
+source, a service worker or null
Output
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 waiting attribute of registrationObject to the ServiceWorker object that represents registration’s waiting worker, or null if registration’s waiting worker is null.
Queue a task to set the waiting attribute of registrationObject to the ServiceWorker object that represents registration’s waiting worker, or null if registration’s waiting worker is null.
Input
worker, a service worker
+worker, a service worker
state, a service worker's state
+state, a service worker's state
Output
Set worker’s state to state.
+Set worker’s state to state.
Let workerObjects be an array containing all the ServiceWorker objects associated with worker.
Set the state attribute of workerObject to the value (in ServiceWorkerState enumeration) corresponding to the first matching statement, switching on worker’s state:
Set the state attribute of workerObject to the value (in ServiceWorkerState enumeration) 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 the oninstall event 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 the oninstall event 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 the onactivate event 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 the onactivate event 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 statechange at workerObject.
Output
worker, a service worker
+worker, a service worker
Output
newestWorker, a service worker
+newestWorker, a service worker
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.
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.
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:
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.
@@ -7524,35 +7510,35 @@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.
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.
@@ -2901,7 +2895,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:
An ExtendableEvent object has an associated extend lifetime promises (an array of promises). It is initially an empty array.
An ExtendableEvent object has an associated extensions allowed flag. It is initially set.
Service workers have two lifecycle events, install and activate. Service workers use the ExtendableEvent interface for activate event and install event.
Service workers have two lifecycle events, install and activate. Service workers use the ExtendableEvent interface for activate event and install event.
Service worker extensions that define event handlers may also use or extend the ExtendableEvent interface.
Note: To extend the lifetime of a service worker, algorithms that dispatch events using the ExtendableEvent interface 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 ExtendableEvent interface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch and Handle Functional Event.
event.waitUntil(f)waitUntil() method extends the lifetime of the event.
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 install event and activate event, 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 install event and activate event, 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 ServiceWorkerGlobalScope object 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 ServiceWorkerGlobalScope object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
Service workers have an essential functional event fetch. For fetch event, service workers use the FetchEvent interface which extends the ExtendableEvent interface.
Service workers have an essential functional event fetch. For fetch event, service workers use the FetchEvent interface which extends the ExtendableEvent interface.
Each event using FetchEvent interface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:
Service workers define the extendable message event to allow extending the lifetime of the event. For the message event, service workers use the ExtendableMessageEvent interface which extends the ExtendableEvent interface.
Service workers define the extendable message event to allow extending the lifetime of the event. For the message event, service workers use the ExtendableMessageEvent interface which extends the ExtendableEvent interface.
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.
@@ -3200,11 +3194,11 @@install
ExtendableEvent
- activate
ExtendableEvent
- fetch
FetchEvent
@@ -3229,7 +3223,7 @@ The Cache instances are not part of the browser’s HTTP cache. The Cache objects are exactly what authors have to manage themselves. The Cache objects do not get updated unless authors explicitly request them to be. The Cache objects do not expire unless authors delete the entries. The Cache 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 service worker that can safely operate on.
The Cache instances are not part of the browser’s HTTP cache. The Cache objects are exactly what authors have to manage themselves. The Cache objects do not get updated unless authors explicitly request them to be. The Cache objects do not expire unless authors delete the entries. The Cache 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 service worker that can safely operate on.
self.cachesService 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/128 for 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/128 for 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.
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 Content-Security-Policy HTTP header containing the value policy, the user agent must enforce policy for serviceWorker.
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.
importScripts(urls)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 allowing Caches to fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the Cache as Response objects whose corresponding responses are basic filtered response, the objects stored are Response objects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed to event.respondWith(r) method in the same manner as the Response objects 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. Allowing Caches to 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 allowing Caches to fetch and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the Cache as Response objects whose corresponding responses are basic filtered response, the objects stored are Response objects whose corresponding responses are either CORS filtered responses or opaque filtered responses. They can be passed to event.respondWith(r) method in the same manner as the Response objects 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. Allowing Caches to store them allows applications to avoid re-architecting in most cases.
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 dispatching fetch event.
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 dispatching fetch event.
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.
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.
Service workers are extensible from other specifications.
+Service workers are extensible from other specifications.
Specifications may define an API tied to a service worker registration by using partial interface definition to the ServiceWorkerRegistration interface where it may define the specification specific attributes and methods:
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 ServiceWorkerGlobalScope object) 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.
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.
job, a job
worker, a service worker
+worker, a service worker
registration, a service worker registration
Invoke Resolve Job Promise with job and the ServiceWorkerRegistration object which represents registration.
Queue a task to fire an event named updatefound at all the ServiceWorkerRegistration objects 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 updatefound at all the ServiceWorkerRegistration objects 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.
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.
If registration’s waiting worker is null, abort these steps.
+If registration’s waiting worker is null, abort these steps.
Let redundantWorker be null.
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.
Input
serviceWorker, a service worker
+serviceWorker, a service worker
Output
Create a new WorkerLocation object 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.
@@ -4792,7 +4778,7 @@Input
serviceWorker, a service worker
+serviceWorker, a service worker
Output
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.
@@ -4842,11 +4828,11 @@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.
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
@@ -4911,12 +4897,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.
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.
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.
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.
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:
@@ -5142,7 +5128,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.
@@ -5152,7 +5138,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.
@@ -5162,7 +5148,7 @@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.
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.
target, a string (one of "installing", "waiting", and "active")
source, a service worker or null
+source, a service worker or null
Output
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 waiting attribute of registrationObject to the ServiceWorker object that represents registration’s waiting worker, or null if registration’s waiting worker is null.
Queue a task to set the waiting attribute of registrationObject to the ServiceWorker object that represents registration’s waiting worker, or null if registration’s waiting worker is null.
Input
worker, a service worker
+worker, a service worker
state, a service worker's state
+state, a service worker's state
Output
Set worker’s state to state.
+Set worker’s state to state.
Let workerObjects be an array containing all the ServiceWorker objects associated with worker.
Set the state attribute of workerObject to the value (in ServiceWorkerState enumeration) corresponding to the first matching statement, switching on worker’s state:
Set the state attribute of workerObject to the value (in ServiceWorkerState enumeration) 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 the oninstall event 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 the oninstall event 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 the onactivate event 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 the onactivate event 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 statechange at workerObject.
Output
newestWorker, a service worker
+newestWorker, a service worker
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.
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.
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:
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.
@@ -6820,31 +6806,31 @@