Subsequent subresource requests' sources follow the navigation request's source.

[yoshisatoyanagisawa]

When we consider the use case like using the static routing API as compliment to the ServiceWorker scope, it should be natural to make the subsequent subresource requests follow the navigation request's source. It means that if the navigation request's source is "network", the subsequent requests also goes "network".

For example, if a developer does not want "/form/*" to use ServiceWorker, it is natural expectation to avoid using ServiceWorker for images or scripts imported from there even if the images or the scripts are out of "/form/*". It brings the same mental model with the ServiceWorker scope.

[ralphch0]

Would prefer to keep the flexibility to do both though. I can see a site wanting to start using service workers to speed up or improving caching of static resources, but want to roll this out without affecting the perf of the initial navigation.
So would prefer either a rule can decide (e.g. skipSubsequentRequests=true), or add a sourceUrlPattern condition (arguably more flexible, as it can allow you to capture some subset of the subresources).

[yoshisatoyanagisawa]

Allowing both sounds reasonable to me. At the same time, if we follow Service worker scope's mental model, such inheriting behavior should always starts from navigation request and subresource request cannot start that. From that perspective, I prefer adding a sourceUrlPattern condition (this sounds only applicable to navigation request) to allowing a rule to decide.

[ralphch0]

Sry, not sure I got which option you are recommending 1) navigation rule decides for all subresource, or 2) individual subresource rule can decide using a source regex.

You mention sourceUrlPattern which makes me think of #2, but you also mention "this sounds only applicable to navigation request".

re: SW scope mental model, it seems that we are already outside of that here. Since the router acts on a per request basis, not a per navigation basis (unlike SW scope which works only on the navigation). So for this reason, I think it makes sense to continue that model here and say requests are always independent, but devs can create a request rule that is conditional on the originating page.

[yoshisatoyanagisawa]

For ease of understanding a rule at a glance, I think making rules independent better, and I am leaning on 2) individual subresource rule can decide using a source URLPattern. I understand this is a bit different from the SW scope mental model, though. Also, 1) navigation rule decides for all subresource might not be easy to write in the static routing API rules.

[ralphch0]

+1

[domenic]

I was asked for my opinion on this issue, but I don't think I understand it very well. In particular, I don't understand the proposals people are making, or what different code they would result in.

For example, if a developer does not want "/form/" to use ServiceWorker, it is natural expectation to avoid using ServiceWorker for images or scripts imported from there even if the images or the scripts are out of "/form/".

Hmm. I don't understand this natural expectation, personally. If my router says to only handle /form/*, why would some other URL, which doesn't match that pattern, be handled by the routing rules?

[ralphch0]

I can provide a practical example here:

• Multiple applications live on the same domain
• A SW is installed at the domain root url, in order to redirect "/" to one of the specific applications that support offline.
• The SW should not interfere or have a performance impact on the other applications that don't support offline.

It would be useful to configure the static routing to skip the service worker for all static resources fetched by the applications that don't support offline.

[domenic]

I see, so this is proposing to add a "dynamic routing" mode to the router, where the treatment of a URL is no longer based on static routes, but instead based on what initiator URL caused the fetch? I wonder how that works when multiple initiators request the same subresource, e.g. with multiple tabs open controlled by the same service worker...

[ralphch0]

Yes, but I wouldn't call it dynamic, since these are still conditions captured and executed by the browser, rather than decided on demand by app-provided js when the fetch happens.
This would just add a new condition (similar to urlPattern condition), but rather than applying on the resource's url, it would apply on the url of the initiator page/context. This would allow a static resource to be treated differently depending on which page it's coming from.