Re: [ServiceWorker] Cancelling HTTP fetch (#592)

(I thought we were discussing this particular API problem in https://github.com/slightlyoff/ServiceWorker/issues/625 but I'm happy to move it here.)

@tyoshino we could create `FetchInit : RequestInit` (inherited dictionary) for `fetch()`. I think we should have something distinct from `Request`. @wanderview convinced me that treating `Request` as more than just input (or output in case of a service worker fetch event) is problematic. Various things from the original `Request` object might not end up being taken into account. `fetch()` only modifying parts of the input but not others would be weird.

So that leaves us with either a promise subclass or controller of sorts. Given the promise discussions on es-discuss it seems like we want a controller.

And as far as @domenic's question goes I think it should be a mechanism that cancels the promise and the stream. The action is terminating network activity. The only worry I have is that the code gets a little awkward:

    var c = new FetchController,
        resp = fetch(url, { controller: c })
    c.abort()

Also, if we go down this route I think the controller object should also expose state whether it is in use or not. And `fetch()` will throw if it is passed a controller that is already in use. Or do we want to allow for the ability of a single controller controlling several fetches?

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

Received on Thursday, 19 March 2015 10:07:00 UTC