Direct download fails on seafile/nextcloud server

[eDeviser]

I'm hosting a webserver with seafile.
When I click on the Download link direktly, then choosing the app for opening, the Download
aborts because of Http400 Error. This could be because the Download token
from the server are working just for one time. Nevertheless, if do
rightclick on the download link and select "save as", the download works
pretty fine.

I think, when clicking on such a link, a request to the server is issued, which invalidates the
link for subsequent requests. The headers from the response to that request are then passed to the download manager which will initiate the download by issuing the request again, and the first request
initiated by the browser is cancelled. That’s indeed a bug in how
downloads are handled in the browser.

If nessesary I can provide a temporary download link for testing the issues.

This happend on my Nexus 4 with OTA9.

[Olivier Tilloy (osomon)]

Sounds like this is yet another limitation of the way downloads are handled in oxide/webbrowser-app. We would need a tighter integration of the ubuntu download manager in oxide to overcome this limitation.

Could you please confirm that the duplicated request is indeed the cause of the problem, by checking the logs of your webserver?

Thanks!

[eDeviser (wolle3)]

Hey Olive! I am acutally not totally shure, that the problem is within Ubuntu Touch, because I am just a Embedded Software Developer hosting a webserver for fun. But in seafile/Forum, they told me it is not a problem with the seafileWebserver. They told that it is caused by the oneTimeTokens. Nevertheless downloads seems to be handled different, if they are done by direct clicking or using reightClick>SaveAs. So here are the logfiles:

>>This are the LogFiles with direkt clicking the download Link, they ended up with the http400 error:
/var/log/nginx $ tail -f seahub.access.log
192.168.0.11 - - [28/Feb/2016:13:19:37 +0100] "GET /lib/8ff5eba7-2ea3-4991-915f-25286518a523/file/2010618_wk42_web_30042010_2.pdf?dl=1 HTTP/1.1" 302 5 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"

/var/log/nginx $ tail -f access.log
192.168.0.11 - - [28/Feb/2016:13:19:37 +0100] "GET /seafhttp/files/61342757-db0f-422c-a6f3-798c1db50e5f/2010618_wk42_web_30042010_2.pdf HTTP/1.1" 200 54237 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"
192.168.0.11 - - [28/Feb/2016:13:19:38 +0100] "GET /seafhttp/files/61342757-db0f-422c-a6f3-798c1db50e5f/2010618_wk42_web_30042010_2.pdf HTTP/1.1" 400 17 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"

>>This are the Logs created by RightClick>SaveAs:
/var/log/nginx $ tail -f access.log
192.168.0.11 - - [28/Feb/2016:13:18:05 +0100] "GET /seafhttp/files/5a575ca4-1dd8-40e6-882e-eb0371779a02/2010618_wk42_web_30042010_2.pdf HTTP/1.1" 200 1652945 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"

/var/log/nginx $ tail -f seahub.access.log
192.168.0.11 - - [28/Feb/2016:13:17:54 +0100] "GET /ajax/unseen-notices-count/?_=1456660224104 HTTP/1.1" 200 22 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"
192.168.0.11 - - [28/Feb/2016:13:18:00 +0100] "GET /lib/8ff5eba7-2ea3-4991-915f-25286518a523/file/2010618_wk42_web_30042010_2.pdf?dl=1 HTTP/1.1" 302 5 "http://myserver.de/" "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"

[Olivier Tilloy (osomon)]

Not sure what you mean by "right click > Save As", there is no such option in webbrowser-app. There is a "Save link" option, but it should behave exactly the same as a left click for e.g. a PDF document.

Can you elaborate on what this right click thing is, and if it allows you to successfully download files?

Also, if you could provide a temporary download link for testing purposes, that’d be great (feel free to ping me on IRC, I’m oSoMoN on Freenode, or by e-mail to olivier [dot] tilloy [at] canonical [dot] com). Thanks!

[eDeviser (wolle3)]

Hey Oliver,
thanks for reply. I'm sorry, I always talked about 'right click > Save As' but I meant 'right click > Save link'.

If I used the 'right click > Save Link' option, the download finishes successfully.
But if I do left click on that link, the download aborts with http400 error.
This behavior is the same for all filetypes.

See my temporary link, which I'll send via email to you.

You can also take a look at my request to the server side software: https://forum.seafile-server.org/t/http-400-error-on-download/3767/6

[Olivier Tilloy (osomon)]

eDeviser: I was able to observe the issue firsthand thanks to the test credentials provided by Lukas (thanks!).

What I’m seeing is that tapping/clicking on a text file (the only file I have handy in the test instance) displays the contents of that file on a page. That page has a "Download" button, which, when clicked, triggers the HTTP 400 error. The URL that it tries to download when this fails is of the form http://[domain]/seafhttp/files/[uniqueID]/filename.txt.

Now when I get back to the file listing, if I long-press on the text file and choose "save link" from the context menu, the download goes through and the URL downloaded is of the form http://[domain]/lib/[uniqueID]/file/filename.txt. However the contents of the file that was actually downloaded is a HTML login page, not the text file.

Can you please confirm you’re seeing the same?

[eDeviser (wolle3)]

Hello Oliver,

Thanks for your reply. I see, I have to make a better description of how to use my homepage and how to force the error.
After you logged into the test account, I sent to you, you see a Library. Open that library by clicking once to it. Then you see all files which are currently in this library. Click once to one of the files. Then you will see a Download Button and if the filetype is .pdf or .txt you will see a preview embedded to the homepage. On this Download Button just do:

->Click once to produce the http400 error
->Click right or tap for a long time to open the context menu and select 'save link' to download the file without errors.

PS: You can upload and downlaod and delete any files on that testaccount I sent to you. So feel free to explore the behavior with any filetype, the behavior should be the same. But remember, the test account has just a few megabytes of storage space.

[Olivier Tilloy (osomon)]

OK, I can reproduce the issue described in comment #6 indeed.

I’m seeing one major difference: when clicking the download button directly, the name of the file being downloaded is "Psalm23.txt", whereas with right-click and "save link", the file name is "Psalm23.txt?dl=1".

That "dl=1" parameter seems to make a whole difference.

[Olivier Tilloy (osomon)]

The code for the download button on the file’s preview page is as follows:

    <a class="btn-link" href="?dl=1" id="download">Download</a>

[Olivier Tilloy (osomon)]

And I just verified that in the WebView’s onDownloadRequested signal handler, request.url is different in each case:

  left click: http://powered.spdns.de/lib/1a5035f8-cd5d-4231-83ad-770b0ca096a3/file/Psalm23.txt

  right click to save link: http://powered.spdns.de/lib/1a5035f8-cd5d-4231-83ad-770b0ca096a3/file/Psalm23.txt?dl=1

[Olivier Tilloy (osomon)]

The original HTTP request that happens when clicking the download button looks like this:

GET /lib/1a5035f8-cd5d-4231-83ad-770b0ca096a3/file/Psalm23.txt?dl=1 HTTP/1.1

HTTP/1.1 302 FOUND
Location: /seafhttp/files/32a0a451-086b-4cbc-b6da-6d80f43df463/Psalm23.txt

GET /seafhttp/files/32a0a451-086b-4cbc-b6da-6d80f43df463/Psalm23.txt HTTP/1.1

HTTP/1.1 200 OK
Content-Disposition: attachment;filename="Psalm23.txt"
[contents of the file]

Now when confirming the download in the browser, the request looks like this:

GET /seafhttp/files/32a0a451-086b-4cbc-b6da-6d80f43df463/Psalm23.txt HTTP/1.1

HTTP/1.1 400 Bad Request
Bad access token

[Olivier Tilloy (osomon)]

Same issue when downloading files from the nextcloud UI:

::1 - - [15/Nov/2016:15:26:20 +0100] "GET
/nextcloud/remote.php/webdav/movie.mp4?downloadStartSecret=pjpu0984pl3odl9sbz0itqpvi
HTTP/1.1" 200 189307 "-" "Mozilla/5.0 (Linux; Ubuntu 16.04)
AppleWebKit/537.36 Chromium/54.0.2840.71 Safari/537.36"

127.0.0.1 - - [15/Nov/2016:15:26:27 +0100] "GET
/nextcloud/remote.php/webdav/movie.mp4?downloadStartSecret=pjpu0984pl3odl9sbz0itqpvi
HTTP/1.1" 401 1194 "-" "Mozilla/5.0 (Linux; Ubuntu 16.04)
AppleWebKit/537.36 Chromium/54.0.2840.71 Safari/537.36"

(the first request is issued by webbrowser-app when clicking the "Download" button, the second one is issued by UDM when starting the actual download)

[Olivier Tilloy (osomon)]

(initially reported in https://lists.launchpad.net/ubuntu-phone/msg22840.html for nextcloud)

[eDeviser (wolle3)]

Thank you Oliver for your great work!

I have a proposal for a user experience which does not need to do two requests:

Every download could be directed directly to the Downloadmanager.
A short notification, which could look like the new message or volume changed notification, should be shown to tell the user, that the download has been started.
When the Download is finished a dialogue could be shown, which lets the user choose between opening the file with an app or simply do nothing.

[Olivier Tilloy (osomon)]

> Every download could be directed directly to the Downloadmanager.

Oxide doesn’t know that a download is a download until it has issued the request and gotten a response. So it can’t delegate the download to UDM upfront. What has to happen for this use case to work, is that downloads need to be handled by oxide itself (but that has serious implications on the strict lifecycle policies).