init file download via POST

[blizzz]

Currently file downloads are triggered by a regular GET request through changing the window location. This can leak file names, but also limits the number of downloadable files for URL length restrictions.

~~By switching to a POST request (thus through XHR) we can avoid both aspects. The downside with the chosen method is, that it does not stream the data: the UI is not blocked, but the browser's download progress does not kick in and the save dialog appears only after the file is downloaded. ~~

• Hence, there is not visual feedback.

Switch to register the download action via POST call that provides all the information. A token is returned, which is then passed along by the GET request through location change. Save dialogue is shown immediately and the browser progress indicator works again, too.

As far as I researched there is no way around with XHR (no stream support by design). Streams API offer support, alas – as far as i know - still would suffer the same problems around the built-in progress bar and save dialog (and cannot be backported for lack of IE support).

Another approach would be to use the progress indicator as with file uploads with downloads, too. But maybe I also oversaw an option?

Now:

• download on sharing pages is broken
• tests
• and the open review remarks

[blizzz]

An alternative that would keep the browser's download progress would be to announce the download with a post-request, the returns a token, and then trigger the download again by GET but only providing the token as parameter.

[skjnldsv]

the browser's download progress does not kick in and the save dialog appears only after the file is downloaded.

For me that is a huge issue.
If we do this, like big hosting companies are doing (mega was one of the first), we need to show a progress bar. What if the file is 20GB, will I have to wait for 1h to see the file save dialog?

[PVince81]

An alternative that would keep the browser's download progress would be to announce the download with a post-request, the returns a token, and then trigger the download again by GET but only providing the token as parameter.

Somehow reminds me of pre-signed download URLs, which are a slightly different thing though.

[blizzz]

An alternative that would keep the browser's download progress would be to announce the download with a post-request, the returns a token, and then trigger the download again by GET but only providing the token as parameter.

This is now implemented.

On smoke testing it of course turned out that sharing needs extra care. There is duplication to some degree, so that's still to tackle.

[skjnldsv]

I would argue that the service file name is a bit too simple and confusing.
But it's no blocker:

Something like ?

Suggested change

	import download from './services/Download'
	import download from './services/DownloadFileService'

[blizzz]

Okay. Just, service is now duplicated (in the path), and what else do you download other than files? It's also actually executing a download. You could argue whether the business logic (register first, then execute), however I think that's an implementation detail here.

[blizzz]

unfinished and not and the table, closing.