Re: [fetch] Aborting a fetch (#27)

While `cancel` / `abort` isn't wrong, most of the time (for me) the intent is actually `free` or `deprecate`. I want to free that network request to both not have the client handle irrelevant data (if possible), or stop the server from processing it (when its very costly to compute). Sometimes throttling user actions just isn't good enough.

I've skimmed though the discussion, so sorry if I somehow missed this being discussed already (I've only seen brief mentions of similar suggestions). 

**What's the problem with ignoring the Promise altogether?**

*Example*

```javascript
// Normal use case. Not possible to stop.
var p = fetch('http://someplace'); // => Promise
```
```javascript
// When you need to be able to stop it you do this.
var fh = fetch('http://someplace', { returnType: 'handle' }); // => FetchRequestType
var p = fh.promise(); // => Promise (equivalent to normal fetch)

// "May" stop the request in which case the promise will be dropped. There is no error 
// or resolution, the promise just never resolves or errors out. If content is already 
// being streamed in, then it does nothing and just lets it finish.
fh.deprecate();
```

The `deprecate` methods can have options to let the user decide how liberal `fetch` can be with `abort`ing and how it should handle the `abort` case. I don't believe its hard to implement most variations as options and by default its probably unsafe to abort once content has trickled down unless the user explicitly asks for it, or fetch can determine that the partial content streamed down is still only known to itself, so...

```javascript
// Same as no options, but forcefully interrupts content streaming whatever you got 
// so far becomes last byte sent. User is responsible for handling the partial data.
fh.deprecate({ bodyInterrupt: true });

// Same as no options but forces Promise error handler if fetch decides to abort.
fh.deprecate({ onHeaderAbortTriggerError: someAbortError });

// Same as above only trigger success instead of error if fetch decides to abort.
fh.deprecate({ onHeaderAbortTriggerSuccess: someAlternativeSuccessBody });

// ...whatever other options people want
```

Deprecating a request would not guarantee an `abort`. An `abort` would simply be one possible outcome.

-

Ignoring the promise should work with current promise implementations just fine, but it would probably be ideal for `Promise` to support `deprecate` as well (ie. explicitly specify that the promise is now "garbage" and should neither resolve nor error out). While I would assume javascript engines would (or should) be able to figure out the promises in question and related handlers are garbage with out it being explicit, unhandled Promise checkers would probably have issues with them (though I believe only Promise libraries actually implement anything of the sort at the moment).

If this still results in "complications" then, as suggested earlier, ideally just make it so once user asks to work with "cancellation" the concept of getting a promise is just thrown out the window. Promises may be new and shiny and solve a lot of problems, but there's no reason to force ALL problems on them.


---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-184258383