Я провел некоторое тестирование, и у меня возникли некоторые проблемы с потоковой передачей файла, предназначенного для загрузки (с заголовком Content-Disposition, установленным на attachment в ответе).Следующее поведение является общим для Firefox и Chrome, и я назову «браузер» сущностью, которая выполняет код, который не является кодом, написанным пользователем.
Поток начинает потребляться прямоотсутствует, когда ответ отправляется обратно с event.respondWith(), что означает, что, пока появляется всплывающее окно, чтобы спросить пользователя, хочет ли он и где скачать файл, или если он просто хочет отказаться от загрузки, поток используется и извлекает данные без-стоп.Это кажется сумасшедшим поведением, это намерение или ошибка в обоих браузерах?
Если пользователь отказывается от загрузки или принимает и отменяет ее позже, браузер просто прекращает потребление потокаи это все.Он никогда не вызывает cancel() в своем экземпляре ReadableStreamDefaultReader и не вызывает releaseLock().Поэтому поток просто извлекает данные из базового источника, пока очередь не заполнится, и ждет там, ничего не зная.Как нам с этим бороться?
Из спецификации Streams (https://streams.spec.whatwg.org/#rs-cancel):
Метод отмены отменяет поток, сигнализируя о потере интересав потоке потребителем. Предоставленный аргумент причины будет передан базовому источнику cancel (), который может или не может его использовать.
Так что я думаю, что браузер должен вызывать cancel для своегоReadableStreamDefaultReader экземпляр, но ни Firefox, ни Chrome не делают.
Более того, если я вызову метод error для базового экземпляра
ReadableStreamDefaultController потока, браузер по-прежнему никогда не снимает блокировку.