Re: [ServiceWorker] Interception of the fallback requests initiated from a SW for cross-origin resources (#684)

Per conversations in SF today, a few points that seem relevant:

 - Moving the registration (`e.handleFallThroughRequests(['/resources', '/font']);`) to `onactivate` is non-controversial. Registrations overwrite each other and last-one-wins semantics prevail.
 - We need an API for examining the fall-through registrations
 - The fall-through handler (e.g., `b.com`'s handler for a fetch that `a.com` generates) should probably have a different event name, e.g. `onfallthroughfetch` to prevent naive reuse of `onfetch` logic that isn't suited to dealing with requests from third parties
 - CORS is hard. Logically, any `fetch()` from `a.com`, either from it's documents or Service Workers, that reach a fallthrough event handler should allow `b.com`'s `onfallthroughfetch` to see CORS preflights and respond appropriately. Logically speaking, `b.com`'s SW _is_ executing across the network from `a.com`'s perspective
 - To prevent abuse, responses from `onfallthroughfetch` should probably be made opaque by default and explicit action, perhaps in the form of a different `Response` object type or an argument to `respondWith` should be necessary to make a response non-opaque.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/684#issuecomment-108115054

Received on Tuesday, 2 June 2015 22:20:38 UTC