Re: [ServiceWorker] Returning a FetchPromise from fetch() (#625)

It obviously shouldn't.  ^_^

This is an ambient authority bug, caused by the abort capability being carried along by default to all the chained promises.  You really do have to be strict about whether an object is multicast or unicast; if you work with a unicast object in a multicast way, it needs to act multicast, and not expose dangerous capabilities.

The proper way to handle this is:

```javascript
var fetchTask = fetch(url);
var jsonTask = fetchTask.pipe(r => r.clone().json());
var textTask = fetchTask.pipe(r => r.text());

textTask.abort(); // aborts the textTask operation, but leaves fetchTask alone
jsonTask.abort(); // now that all consumers are aborted, fetchTask can abort too
```

In other words, you need to ref-count your clients with abort capabilities if you want to be able to propagate aborts up the chain.  You don't want to give that out by default; it'll just mean that aborts rarely propagate.  You need to be able to both pass out the ability to *observe the result* (a normal Promise) and the higher-powered ability to manipulate the fetch, and these need to be separate operations.

Alternately, you could just use standard `.then()` for this behavior, and require people to do `Promise.resolve(fetchTask)` when they want to hand out the result of the fetch without increasing the refcount (both giving out the ability to abort the fetch, and making it harder for other clients to abort the fetch).  But let's be honest, that won't actually happen in most code.  I'm not sure how much we want to value the different ergonomics.

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