1579456 - downloads: Allow to adjust the name upon URL changes (redirect) or server suggested names (Content-Disposition)

Status: RESOLVED DUPLICATE of bug 1245652

(WebExtensions :: General, enhancement, P5)

Description

[Nils Maier [:nmaier]]

The WebExtension downloads API allows users to specify a file name, including sub-directories, which is great for extensions that e.g. do some for of automated sorting.

However, there is no way to adjust this file name once the download has started. Adjusting it may become necessary, however, when the URL changes upon redirects, or when the server replies with Content-Disposition: filename= or Content-Disposition: filename= (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition).

A lot of servers use the HTTP header (e.g. every bugzilla instance for attachment.cgi ;) and even more use redirects.

What's more is that the downloads API (and DownloadsCore's DownloadCopySaver) completely ignores the header, so saving with the downloads API e.g. https://bug1578955.bmoattachments.org/attachment.cgi?id=9090591 while not providing any file name at all will save it to attachment.cgi... not really helpful...

So my idea is to add a new feature to the downloads API that allows an API consumer to adjust the name as redirects are encountered or headers become available.
Now the question is: how?

0. Do nothing and let extensions do nasty work arounds, like an initial fetch request to determine the final redirect URL, if any, or the Content-Disposition header, if any.
   • Con: If extension does nothing, users will have a sadface
   • Con: If worked around, extensions waste time and resources, both locally and server-side
   • Con: If worked around, the downloads may fail (there are servers which will allow an URL to be hit exactly once, and this attempt would have been used already if the extension did a fetch before the actual download).
   • Con: if worked around, extensions would need additional permission that they otherwise might not need, in order to be allowed to fetch for example.
1. A callback in the create() options.
   • Pro: Simple-ish interface and zero cost when omitted
   • Con: Can only see downloads created by the corresponding extension
2. A general set of onRedirect/onServerName listeners that would allow any extension to modify any download.
   • Pro: An extension can react to all downloads it created
   • Con: Extensions may fight (there can be only one winner)
   • Con: never zero cost, as potential listeners have to be notified always.

This would require a sizable amount of changes and hackery, as with either option we want to delay moving the download into it's final location on disk until all listeners responded.

Thoughts?
Any other people to solicit input from?

Comment 1

[Rob Wu [:robwu]]

The onDeterminingFilename event is supposed to provide this functionality - bug 1245652.

The downloads API implementation in Firefox fixes the file name before the download has started.
If I recall correctly, Chrome fixes the filename only after the headers have been received.
We should also implement that behavior, but it would be part of bug 1245652.

Nils, would bug 1245652 address your use cases?

Comment 2

[Nils Maier [:nmaier]]

I forgot about onDeterminingFilename indeed. It is a rather clumsy API, and you cannot tell why a name was suggested with it, but it's still "good enough" for my use case if it works, I suppose.