- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Thu, 24 Sep 2015 16:09:47 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/pull/751/r40384615@github.com>
> @@ -3589,6 +3632,148 @@ <h2 id="status">Status of This Document</h2> > </spec-algorithm> > </spec-section> > > + <spec-section id="foreign-fetch-scope-match-algorithm"> > + <h1>Match Service Worker for Foreign Fetch</h1> I'm not entirely convinced that the behavior I described here is the behavior we want. In particular I wonder what would be less surprising behavior in the following situations: - Two SW registrations, SW1 with scope "/", and SW2 with scope "/subscope/" - SW1 registers for foreign fetch with scope "/" - Do cross origin resource requests to "/subscope/foo/bar" get intercepted by SW1? - SW2 now registers for foreign fetch with scope "/subscope/" - Now which worker gets to handle foreign fetch events for "/subscope/foo/bar"? - A new version of SW1 now registers for foreign fetch with scope "/subscope/foo" - Now where do foreign fetch events for "/subscope/foo/bar" go? In my proposed algorithm as long as SW2 is around foreign fetch events for "/subscope/foo/bar" will never go to SW1. I think that might be the easiest to understand, except in the last case it does mean that SW1 effectively registered for foreign fetch with a scope that can never receive events as long as SW2 is around, which might be surprising. --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/pull/751/files#r40384615
Received on Thursday, 24 September 2015 23:10:18 UTC