Add Register a Service Worker algorithm for use by other specifications

[monica-ch]

Part of #1846.

This introduces a new exported algorithm — a stable public surface that external specifications can bind to.

Change

Adds an exported Register a Service Worker algorithm so other specifications such as FedCM and Payment Handler can register a service worker without a client-driven flow.

It also extracts the URL checks from Start Register into a shared Validate and Normalize a Service Worker URL algorithm. Both JavaScript registration and browser-initiated registration now use the same rules:

• remove URL fragments;
• require an HTTP or HTTPS scheme; and
• reject paths containing encoded / or \ characters.

The existing JavaScript behavior is preserved: invalid URLs reject the register() promise with TypeError, and a missing scope still defaults to the script URL's directory. The exported algorithm is fire-and-forget and returns when validation fails.

Exported algorithm

Input: storage key, script URL, scope URL, worker type, and update-via-cache mode
Output: none

The algorithm validates and normalizes the URLs, requires the script and scope to be same-origin, checks that the script origin is potentially trustworthy, creates a register job with a null client and promise, and schedules it.

Because there is no calling service worker client, the algorithm sets the job's referrer to the normalized script URL. This allows the existing Register same-origin checks to remain the canonical enforcement point.

Adoption implications

• FedCM (Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842) and Payment Handler can use this instead of invoking non-exported job algorithms directly.
• The (storageKey, scriptURL, scopeURL, workerType, updateViaCache) signature becomes a stability commitment.
• Registration remains asynchronous and fire-and-forget; no completion or failure signal is returned.

Related

• Export SW primitives needed by FedCM and Payment Handler for JIT registration #1846 — umbrella issue
• Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842 — motivating PR
• Add Request Soft Update algorithm for use by other specifications #1847 — Request Soft Update
• Add Unregister Service Workers algorithm for use by other specifications #1849 — Unregister Service Workers

---

Preview | Diff

[monica-ch]

@yoshisatoyanagisawa CYTAL, thanks!

[yoshisatoyanagisawa]

I assume that Start Register (https://w3c.github.io/ServiceWorker/#start-register) does more validation inside. However, such validation looks not implemented here. For example, a scheme is limited to HTTP/HTTPS, a hash will be omitted, etc.

[monica-ch]

Addressed in e053de5. I extracted the fragment removal, HTTP/HTTPS scheme check, and encoded-slash path check into a shared Validate and Normalize a Service Worker URL algorithm. Both Start Register and the exported Register a Service Worker algorithm now use it, while Start Register retains its existing TypeError rejection and scope-defaulting behavior.

[yoshisatoyanagisawa]

Is it possible to have a common algorithm between an algorithm call via the JavaScript register() and the registration initiated by the browser (this case), and make the latter exported? I assume that the script URL validation can be common between the JavaScript and this.

[monica-ch]

Thanks, @yoshisatoyanagisawa — updated in e053de5. The URL validation and normalization previously embedded in Start Register is now a shared algorithm used by both the JavaScript and browser-initiated registration paths. Client-specific behavior such as promise rejection and storage-key acquisition remains in Start Register.

The shared helper operates on a copy of each URL, so the exported algorithm does not mutate URL records owned by its caller. PTAL when you have a chance.