I noticed that, while the .crdownload temporary is closed and deleted, the controller.enqueue() calls continue to result in writes to the cache.

this is a big deal for us since we're using SW fetch to download and collate parts of muti-100GiB files. if the user cancels and we don't know about it, the cost of wasted bandwidth can add up quickly.

I found it to be problematic to abort a download too. If you throw an error on the ReadableStream controller

> controller.error(new Error('Client aborted the download'))

then you are stuck with a pending download that can't be aborted or closed

Deleted: Skärmavbild 2016-08-23 kl. 23.37.48.png 5.4 KB

	Skärmavbild 2016-08-23 kl. 23.37.48.png 5.4 KB View Download

> jimmy@warting.se
I think the fetch request of download doesn't go to the service worker now. Issue 468227
Is your service worker handing the fetch request of download?

> horo

I'm actually not doing any fetch request, but i'm doing some fetch stuff in the SW. Here is my code:

https://github.com/jimmywarting/StreamSaver.js/blob/18c31f8c0e4f5be9afdeedea0b665a7ce8d2e079/sw.js#L36

Thank you for letting me know your script.
Setting 'attachment' content-disposition can trigger downloads.
I forgot about it.

#7 Your attachment is empty. What did you intend to upload?

We also have a problem with this issue. Our Application triggers a download with a fetch request to the ServiceWorker and respond with a ReadableStream and header "content-disposition attachment". Inside the Reader we fetch encrypted chunks from a server, decrypt them and write the data to the stream. It works pretty good, but if the user cancels the download we have no possibility to stop fetching the encrypted chunks. My expectations is, that if the user is cancelling the download, the ReadableStream should receive the cancel event. At the moment our issue is the same like in Comment 1. Sorry for my rusty english ;)

Greeting Hendrik