Downloading a file requires its mime-type to be known in advance

[Olivier Tilloy]

On touch devices, this is what happens when a user clicks on a link that triggers a download, or triggers one from the context menu:

 - oxide issues a downloadRequested signal with a URL, and optionally headers, a suggested filename and a mime type
 - the browser instantiates a Downloader component and calls its downloadMimeType() method, which converts the passed mime type to a well-known content type (e.g. ContentType.Pictures) and instantiates a SingleDownload component, passing it the headers and content type
 - the SingleDownload instance, once its gets assigned a unique download ID by the DownloadManager, shows a ContentPeerPicker on screen which uses the passed in content type to prompt the user to choose a target application that will own the downloaded file
 - the actual downloading of the file doesn’t start until the user has picked a target application

This works well if the mime type is known in advance, and can be trusted (indeed a server can lie about the mime types of files it serves). In several cases, the mime type isn’t known in advance (or cannot be trusted), and the browser will outright refuse to download the file because it doesn’t know which application to transfer ownership to.

There must be a way to decouple the actual downloading from the target application selection, so that the mime type is not mandatory information, and users can pick which application to transfer ownership to after the file has been downloaded.

========================================================================

Steps to observe the issue (from bug #1510187):

1. Go to <https://bugzilla.mozilla.org/show_bug.cgi?id=299372>.
2. Scroll down to the "Attachments" list.
3. Long-tap on "An idea for a good solution".
4. Choose "Save link".

What happens: "Sorry, there aren't currently any apps installed that can handle this type of content."

What should happen: The Gallery is offered as an app to save the image to.

[Olivier Tilloy (osomon)]

Tentatively added a content-hub and ubuntu-download-manager tasks, although it’s not really clear to me yet how this can be solved.

[Michael Sheldon (michael-sheldon)]

With the new internal downloads branch when we don't have a mime type we just allow the user to download the file to the Downloads directory without choosing an application, then after the download is finished with run Qt's mimetype detection on the final file, we don't currently override the server mimetype if this was provided for us though (we trust the server), perhaps we should do that as well?

[Olivier Tilloy (osomon)]

Yes, we should probably not trust the mimetype provided by the server, if we can extract a valid mime type from the downloaded file.

Also, I’m wondering if downloading directly to the Downloads folder shouldn’t be the default option? What use case doesn’t this cover?

[Michael Sheldon (michael-sheldon)]

We don't really have a default option any more, in the case where we know the mimetype we present the user with both options, and in the case where we don't we just provide them with the download option (see https://docs.google.com/presentation/d/1woHjO8K4iqyVZZlfQ4BXL0DhYbwkEmZ7wvcUhYzHDRk/edit#slide=id.gc87a1f9cb_1_0 for the relevant dialog design). I guess we could however just remove the "Choose an application" option all together, perhaps something to discuss with design?

[Olivier Tilloy (osomon)]

Yes, that sounds like something we should bring up with design, given that the two options, when available, provide redundant functionality. Let’s discuss it today during our weekly design catchup.

[Chris Coulson (chrisccoulson)]

Just to be clear - there aren't really any cases where DownloadRequest.mimeType from Oxide should be trusted to make a decision. Even in the case where the download is triggered on the Content-Disposition header where Oxide does know the mime-type, that mime-type becomes untrustworthy the moment we discard the response and ask someone else to do the download instead - at which point the server could respond with something completely different.

Given the problems with this API in Oxide, I would like us to end up in a position where we can deprecate (and eventually remove) DownloadRequest.mimeType without breaking downloads.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthew Paul Thomas (mpt)]

Fortunately, there is a detailed spec for "probably not trust the mimetype provided by the server". Modern browsers compute the MIME type based mainly on a combination of the supplied MIME type, and the first 512 bytes of the downloaded resource. <https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource> Oxide probably follows this spec already. If the download service is restarting the download (ignoring for the moment the multiple problems with that approach), it should reimplement that spec.

(One of the problems is, as Chris says, that on the second request, the server response may be different, so the MIME type you compute may be different. A pathological example of this would be that the second serving is of a type where the only installed app that can handle it is ... Browser.)

All that aside, if you tap a link, you expect that it might take a while (and if it does, the browser will show some kind of waiting indicator). So the browser can wait for as long as the server takes to begin the response, read the first 512 bytes, compute the MIME type, and then hand it off to the download service.

If you choose "Save Link", it's more difficult: people expect some kind of selection UI within a couple of seconds. So what browsers tend to do is make the request, wait for a couple of seconds for the server to start sending the response, and if it does, set up the picker informed by that response. If the server doesn't respond in time, the browser sets up the picker informed by what it does know already (mainly the URL, which isn't worth much).

If the server hasn't responded within a couple of seconds, you could give it some extra time by putting up a picker containing nothing but a spinner. That would reassure the user for a couple more seconds, but after that you would still need to populate the picker with default choices.

[Olivier Tilloy (osomon)]

Lowering importance as the browser now allows downloading files without choosing a target application upfront.