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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to content-hub in Ubuntu. https://bugs.launchpad.net/bugs/1500742 Title: Downloading a file requires its mime-type to be known in advance Status in content-hub package in Ubuntu: Confirmed Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in webbrowser-app package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1500742/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
