- From: Alex Russell <notifications@github.com>
- Date: Tue, 02 Jun 2015 15:20:11 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/684/108115054@github.com>
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