1

I did some testing and I have some problems with streaming a file meant to be downloaded (with Content-Disposition header set to attachment in the response). The following behaviour is common to both Firefox et Chrome and I'll call 'browser' the entity that executes code that is not code written by the user.

  1. The stream starts being consumed straight away when the response is sent back with event.respondWith(), meaning that while the popup appears to ask the user if he wants and where to download the file or if he simply wants to refuse the download, the stream is being consumed and pulling data non-stop. This seems like a crazy behavior, is it intended, or a bug in both browsers?

  2. If the user refuses the download or accept and cancel it later, the browser just stops consuming the stream and that's it. It never calls cancel() on its ReadableStreamDefaultReader instance, nor does it call releaseLock(). So the stream just pull data from the underlying source until the queue is full and wait there without knowing anything. How are we supposed to deal with it?

From the Streams specification (https://streams.spec.whatwg.org/#rs-cancel):

The cancel method cancels the stream, signaling a loss of interest in the stream by a consumer. The supplied reason argument will be given to the underlying source’s cancel() method, which might or might not use it.

So I think the browser should call cancel on its ReadableStreamDefaultReader instance but neither Firefox nor Chrome does.

  1. Moreover, if I call the error method on the stream's underlying ReadableStreamDefaultController instance, the lock is still never released by the browser.
double-beep
  • 5,031
  • 17
  • 33
  • 41
Khivar
  • 61
  • 4
  • Hello! I'm not sure that you'll get the right sort of response by posting these details on Stack Overflow. If you think you've found an inconsistency that could be improved via changes to the Streams API specification, I'd recommend posting at https://github.com/whatwg/streams/issues/new. If you think you've found a browser bug, I'd recommend posting at https://crbug.com/new for Chrome, and https://bugzilla.mozilla.org/ for Firefox. – Jeff Posnick Mar 25 '19 at 18:29
  • 1
    Hello ! Thank you for your reply and the links. I don't think the Streams API needs to be updated due to these issues but for the bug reporting, that's exactly what I did yesterday. Here are the links if anyone passing by needs them : Firefox : 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1538726 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1538754 3 - https://bugzilla.mozilla.org/show_bug.cgi?id=1538761 Chrome : 1 - https://bugs.chromium.org/p/chromium/issues/detail?id=945600 2/3 - https://bugs.chromium.org/p/chromium/issues/detail?id=638494 – Khivar Mar 26 '19 at 15:46

0 Answers0