I used to work on the specification update to support the
ServiceWorker static routing API
(https://github.com/WICG/service-worker-static-routing-api)
w3c#1686

However, I accidentally closed it by force-sync to the ServiceWorker
specification's repository HEAD.

This CL is for reviving it.

Just trying to add workflows rule to run CI in static_routing_api repository.

revert

Considering the future update of the condition, we should mark the case
handled as one of conditions.  Also, we need to make it extensible.

It was flipped by mistake.

Revive of PR w3c#1686.

Add 'fetch-event' source

- added a note on multiple conditions.
- changed continue to [=continue=].

- remove checking if runningStatus is one of RunningStatus.
- use "will" instead of "should".

- Use ByteString instead USVString for requestMethod.
- typos on forgetting "=" in closing "=]".

- mutual to mutually.
- |or condition| or |or conditions| to |orCondition| or |orConditions|.
- simplify the for loop upon WICG/service-worker-static-routing-api#9.

* Add "cache" source support.
* Use |client| as settingsObject to evaluate COEP.

When the ServiceWorker static routing API is used and source other than
"fetch-event" is used, results are directly returned without running
ServiceWorker.  In that case, we use the request's COEP instead of
ServiceWorker's COEP.

* Make |registration| set.

In the previous specification, |registration| looks null when the
ServiceWorker static routing API is used.
Let me fix that by moving the step after configuring the registration.

* Remove unnecessary blank line.

With this change, cacheName is supported.  It means that if there is
multiple cache storage and developers want to choose which storage to
use, they can specify the storage by cacheName.

…COEP. (#11)

When we designed the ServiceWorker static routing API, it was designed to be offloading simple things ServiceWorkers do. With that concept, if we evaluate the cache COEP, it should not be a request's COEP, but to be a ServiceWorker's COEP to make it behave as an offload.

To make it happen, we set up the ServiceWorkerGlobalScope to be used for the COEP check.
Since we only need ServiceWorkerGlobalScope for CSP checks, this PR separated the Run ServiceWorker
algorithm to ServiceWorkerGlobalScope setup and others, and make it called before the static routing's
cache COEP check if ServiceWorkerGlobalScope is not ready.

* Reflect some of comments in w3c#1701
* Clarified the cache name matching.
* Run soft update during the router is selected.
* Explicitly unset the flag on terminate.
* add definition for agent.
* Use registration's cache map instead of this's.
* renamed to add "flag", but I still need to find a better name.

race-network-and-fetch-handler is a source to allow request to do competition between a network fetch and a fetch handler.  To implement the feature, this CL factored out the process to run a fetch handler in agent.  It is called from both the ServiceWorker static routing API part and the original part.  In the static routing API part, a fetch controller also runs in parallel, and the Handle Fetch algorithm returns a response coming earlier to the queue.

In the previous CLs, there was a mix of the X algorithm and X algorithm.
This CL changes all to the X algorithm when calling the algorithm
defined in this PR.

Co-authored-by: Marijn Kruisselbrink <[email protected]>

… unset` phrase (#14)

* Remove |raceResponseMap|

* Re-format {{ServiceWorkerGlobalScope}} part and move `It is initially unset` phrase

Upon the review request, this CL makes |activeWorker| not modified
in the Setup ServiceWorkerGlobalScope algorithm.  It is the caller's
responsibility to update the active service worker's global scope.

With this change, an effemeral ServiceWorkerGlobalScope can be used
for a cache source in the static routing API.

* Remove |raceResponseMap|

* Re-format {{ServiceWorkerGlobalScope}} part and move `It is initially unset` phrase

* Fix |url| in Lookup Race Response

* Update race handling, lookup race response algorithm