ubuntu-phone team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

On Mon, Oct 26, 2015 at 5:50 PM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> -----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.)

That’s only problematic for the "save link as" use case, where the
user wants to pick a destination folder and a filename. When saving
the link to the default destination folder with the default filename,
we can give some feedback to the user right away (even if it’s only a
spinner).


>> ...
>>> 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.

Agreed. I filed https://launchpad.net/bugs/1510858 to request more
detailed documentation of the 'headers' property.


>>> 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.

Thanks for the multiple examples. I filed
https://launchpad.net/bugs/1510867 to track the problem in oxide.


>>>> - 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.

So maybe we need a download manager inside oxide after all (looks like
without that (1) cannot be solved). Not sure how that would play with
the phone’s strict lifecycle policy, because it would require to be
kept running as long as there is at least one active download.

And then splitting it out of oxide so that it can be reused by a
generic download manager instance sounds tricky. But this can be
investigated.

Can system architects chime in and share their thoughts on the topic?

Thanks,

 Olivier