touch-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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