We often hear a demand for specifying certain set of destination URLs to be intercepted by SW (e.g. #1026, #1373), and this is yet another (lightweight) proposal to address a subset of these using HTTP response headers (therefore it's ephemeral & scoped only to the current navigation).

Proposal: Service-Worker-Fetch-Scope header

• Allows website to return Service-Worker-Fetch-Scope: <url-scope> HTTP response header to main resource requests, so that they can express what URLs should be hit by their SW for the service worker client that is instantiated by the main resource. <url-scope> can be either “none” or a scope URL.
• When this is specified, the service-workers mode of all subresource fetch requests from the service worker client that do NOT prefix-match the given scope
  is set to ”none”, i.e. this makes only the subresource requests that match the scope hit the Service Worker.

Examples:

• Example 1: A site returns Service-Worker-Fetch-Scope: ‘/sw_cache/’ to document requests so that only the subresources whose URL start with /sw_cache/ are intercepted by the SW.
• Example 2: A site starts to return Service-Worker-Fetch-Scope: “none” after a certain period so that it can skip SW after that. (This could be slightly more efficient than scripting this in SWs as UA can skip routing requests entirely if UA can see it in NavPreload response before/during starting a SW) [EDIT: This use case is a bit hand-wavy, maybe we should focus on the first use-case only]

Alternative can be a header that works opposite, e.g. Service-Worker-Ignore-Fetch or something, while I've heard some sentimenet that allowlisting urls could be handier.

Technically this can be a subset of Declarative Routing proposal (#1373) and can potentially be subsumed by the proposal if we decide to implement it. Motivation of this proposal is to see if we can have a smaller, incremental iteration that can be easier to experiment with.