ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Tilloy wrote on 09/10/15 16:46:
> 
> On Fri, Oct 9, 2015 at 4:06 PM, Matthew Paul Thomas 
> <mpt@xxxxxxxxxxxxx> wrote:
> 
> ...
>> 
>> Even if we wanted to, the browser can't easily limit its use of 
>> the download service to just things that are going to open 
>> outside of the browser itself. This is because the browser can't 
>> tell what file type a particular response is going to be, until 
>> it has already started downloading. You know this, because you 
>> reported the bug. :-) <http://launchpad.net/bugs/1500742>
> 
> This is not what that bug is about. Oxide knows what content it’s 
> able to handle, so when it emits a downloadRequested signal, we’re 
> guaranteed that it’s for an actual file to download.

Okay then, for "the browser" read "Oxide": Oxide can't tell whether it
can display a particular resource until it has already started
downloading. This seems to be what is implied by Chris in the bug
report, where he says "we discard the response and ask someone else to
do the download instead".

(If you choose "Save Link", it's not simpler, it's more complicated.
Anything doing the download -- whether it's Oxide, or the download
service -- needs to wait for a couple of seconds for the server to
respond, *and* it needs a fallback answer in case the server doesn't
respond in time, so that the user isn't left thinking that the browser
is slow. The same trick is required to populate a filepicker with a
default filename, and for determining whether the device has enough
storage space to download the file in the first place.)

> ...
>> You might say, well, in those cases we'll just cancel the browser
>> download and get the download service to request it from scratch.
>> But that wouldn't just be wasting time and bandwidth. It would
>> also be sometimes causing the download to fail, because the 
>> download service isn't able to provide those things I listed: 
>> cookies, Referer, POST form payload etc.
> 
> POST requests may not be supported, but the rest already is: a 
> SingleDownload object accepts headers and metadata, which allow 
> passing cookies, a referer, and a user agent, among other things.

Oh, my mistake! I didn't understand what "headers" meant in
<https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/Ubuntu.DownloadManager.SingleDownload/>.

Perhaps that page could include some examples of how to supply cookies
and HTTP authentication as headers.

>> And even if udm grew to include (or use libcurl for) all those 
>> features, it still wouldn't work in the case of POST. 
>> <http://launchpad.net/bugs/1405517> POST requests are not 
>> idempotent, so you can't safely replay them at all. 
>> <https://tools.ietf.org/html/rfc7231#section-4.2.2> It seems to 
>> me that the only safe way for a download, resulting from a POST 
>> request, to be handled by a download service is if the download 
>> service is handling the initial request.
> 
> It seems to me that initiating a file download as a response to a 
> POST request would be abusing the meaning of the verb. But I don’t 
> know that the HTTP specification prevents from doing this. 
> Something we’d need to test for sure, and file a bug if necessary.

One common example is where you need to enter your e-mail address to
download a file. Sometimes this leads you to a landing page with a
download link. Other times, the file downloads directly.

Another is a Web site that lets you convert one filetype to another.
Again, sometimes the form submission takes you to a landing page with
a download link. Other times, it just returns the file.

For example, on <http://convertonlinefree.com/ImageToPDFEN.aspx>, I
can upload an image and choose "Convert". In Firefox, I get a download
dialog. In Safari for iOS, I get a download page. In the Ubuntu
browser, I get ... nothing.

>>> - oxide (and chromium under its hood) has a highly optimized 
>>> engine to perform HTTP requests, tailored especially for the 
>>> browser use-case, that can handle a number of concurrent 
>>> requests. It would be naive to think we can replicate that in 
>>> udm without a significant effort and finite resources, if at 
>>> all possible
>>> 
>>> - that engine is not meant to be easily replaced in chromium, 
>>> trying to do so would result in a significant amount of work 
>>> (again, if at all possible), and an increased maintenance cost
>> 
>> What about the reverse possibility, then: Could udm use oxide 
>> whenever the protocol is http: or https:?
> 
> What would be the benefit of doing that, if the download manager 
> already handles well file downloads (except maybe for those 
> resulting from a POST request, to be investigated)?
> 
> ...

Four benefits: (1) handling POSTs; (2) not having to restart
downloads (slower and less deterministic); (3) not having to
reimplement the MIME Sniffing spec; and (4) not having to reimplement
Oxide code for determining the default filename of a download, and for
determining whether there's enough storage space to download it at all.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYuWd8ACgkQ6PUxNfU6ecravwCffLV54yKKF/qRkWg4iTXQeQpr
i9IAn2XvwSIXPb6JwIS+4nppsZ4QSaDF
=Sp4Y
-----END PGP SIGNATURE-----