HTTP File Download failing

[jvacek]

Bug: When attempting to download files through the webui, both single and multiple, browser reports no file found and download files.

Feature request: Furthermore, not sure tar is the best way to package files for Windows users, zip or rar might be preferable.

Expected Behavior

Bug: Files should download in a tar when selected for download from the te Torrent Details menu

Feature request: I suggest to support zip or rar or 7z in addition of tar.

Current Behavior

Download starts, and immediately ends like this http://prntscr.com/hk13fe

Possible Solution

???

Steps to Reproduce (for bugs)

1. Find a torrent
2. GO to the detials and files
3. Select either one or couple
4. Press download
5. Fail

Context

I'm just tryting to get my files :(

Your Environment

• Version used:
  • Version (stable release) git --no-pager tag
    v 1.0.0
  • Commit ID (development release) git --no-pager log -1

commit e78ce0e24f1d3eb5e5d2c3c92a672936dc642f61
Author: Hyeronimous Zawapete <[email protected]>
Date:   Sat Nov 25 03:55:37 2017 +0100

    Handling multiple rtorrent instances

• Environment name and version (e.g. Chrome 39, node.js 5.4):
  Chrome 62.0.3202.94 (Official Build) (64-bit)
  node --version = v7.10.1
  npm --version = 3.5.2
• Operating System and version:
  Ubuntu 16.04.3

Note

You may try to follow the update procedure described in the README and try again before opening this issue.

GET / 200 20.674 ms - 543
GET /static/css/main.a1f0bff7.css 304 4.842 ms - -
GET /static/js/main.d1f354a4.js 304 3.989 ms - -
GET /auth/verify?1512592471546 200 24.906 ms - 42
GET /static/media/Roboto-regular.f84cb1bf.woff2 304 4.958 ms - -
GET /static/media/Roboto-700.3b38c16e.woff2 304 4.188 ms - -
GET /static/media/Roboto-500.1afbee5a.woff2 304 3.820 ms - -
GET /static/media/Roboto-italic.4dcf65b9.woff2 304 0.842 ms - -
GET /api/settings 304 157.805 ms - -
GET /api/client/settings 304 1424.111 ms - -
POST /api/client/torrent-details 200 1151.566 ms - 940
POST /api/client/torrent-details 200 5.052 ms - 940
GET /api/download?hash=E1E7C0EB00185C6FDBADF80BC2140BC6731600AD&files=0,1,2,3 404 2.418 ms - 30
POST /api/client/torrent-details 200 10.455 ms - 940
GET /api/download?hash=E1E7C0EB00185C6FDBADF80BC2140BC6731600AD&files=0 404 2.907 ms - 30
POST /api/client/torrent-details 200 1302.798 ms - 940

Update by noraj to separate the bug from the feature request.

[dcousens]

Fail

What do you mean by this?
Does it simply cancel instantly?
Does it download a little bit?
Does it download completely?
Details! Screenshots!

[jvacek]

@dcousens

Fail

What do you mean by this?
Does it simply cancel instantly?
Does it download a little bit?
Does it download completely?
Details! Screenshots!

From my initial comment

Download starts, and immediately ends like this http://prntscr.com/hk13fe

To elaborate, after I click the Download button, the browser starts downloading a file that ends in .tar but immediately fails with the error Failed - No file which google explains further over here

[dcousens]

From my initial comment

Sorry, didn't see it.
Personally can't stand the issue template.

@jvacek was the torrent deleted locally?
Is flood on your local machine or across the network?

[jvacek]

@dcousens

Sorry, didn't see it.
no worries :)

Flood and rtorrent are both running on the same remote server. I am accessing this server via HTTPS running through an nginx reverse proxy which is shown below.

 server {
   listen 80;
   listen [::]:80;
   server_name example.com;
   return 302 https://$server_name$request_uri;
}
 server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name example.com;
   proxy_buffering off;

   add_header X-Content-Type-Options nosniff;
   add_header X-XSS-Protection "1; mode=block";
   add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
   add_header Referrer-Policy strict-origin;

   real_ip_header X-Forwarded-For;

   location / {
     proxy_pass http://localhost:3003;
     proxy_http_version 1.1;
     proxy_pass_header Authorization;
     proxy_set_header Host $host;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Connection "";
     proxy_buffering off;
     client_max_body_size 0;
     proxy_read_timeout 36000s;
     proxy_redirect off;
     }
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
}

I am starting up flood by running a screen -dmS flood inside of which i run sudo npm start (horribly screwed my versions up and can only install the necessary packages when root for some weeeeird reason)

Not sure what you mean by the torrent being deleted, but the files I'm trying to download are still on my server, rtorrent can check them and seed them, and they are located in my (non-root) user folder.

Hope this gives some further insight.

[dcousens]

Try adding proxy_max_temp_file_size 0;
Potentially try re-enable proxy_buffering too

[jvacek]

@dcousens still fails with both edits in the nginx config

[dcousens]

GET /api/download?hash=E1E7C0EB00185C6FDBADF80BC2140BC6731600AD&files=0,1,2,3 404 2.418 ms - 30

Well wait up, thats a 404.
Related lines of code: https://github.com/jfurrow/flood/blob/bba07ed3dea3e1edd0045f5cfe6c63e548a0800a/server/models/client.js#L84-L90

[dcousens]

404 2.418 ms - 30

> JSON.stringify({error: 'Torrent not found.'}).length
30

Matches your 404 error body size... so torrentService.getTorrent(hash); is failing https://github.com/jfurrow/flood/blob/ba69c93bd611e63f3db1207c1dc35cca45ab3a69/server/services/torrentService.js#L192-L194

[jvacek]

Let me know if I can do some more debugging for you. Do keep in mind I'm having some node/npm version issues and am currently running the #549 PR

[noraj]

Note about @jvacek feature request (zip or rar instead of tar): tar is designed for archive without compression and keep a trace of linux permissions, rar is proprietary the code for unraring is open-source and can be used by multiple software but code for creating a rar archive in closed source and not available the only exception is winrar so flood won't be able to rar, zip is designed to be used with compression (that take a lot of cpu both for compressing or uncompressing) and mayebe a lot of lib won't allow you to change the compression algorithm or ratio (to put it to none/0% in order to have the same behavior that we have with tar). Finally tar can be easily extracted on windows with 7z or variosu tool so I don't see the need of supporting zip (and rar can't). Even if a zip support is adding we should need to add a config option to switch from one to the other and not to replace tar by zip.

[jvacek]

@noraj1337 thanks for this background info. I see, makes a lot more sense now.

[noraj]

@jvacek I took the liberty to modify your issue for more clarity:

Update by noraj to separate the bug from the feature request.

[jfurrow]

Can anyone else reproduce this bug? It's working as expected for me.

[jvacek]

After trying this out on the latest version on master, I can only so far reproduce this in firefox, but there is nothing at all in the log. But it works in Chrome for me now.

[d0tfile]

I can download via Chromium, but can't via Firefox. No errors, just nothing happens.

[SanPilot]

Someone try rolling back to 8fc26. This is last commit before Flood switched to piped downloads.

Edit: Or cherry pick df2dd out if possible.

[d0tfile]

@SanPilot both 8fc26ef and df2dd00: button Download do nothing, but from torrent details i'm able to download (Tested on Firefox).

[noraj]

Fixing this:

Feature request: I suggest to support zip or rar or 7z in addition of tar.

Will also fix TAR archives w/ extended headers have limited Windows compatibility #606

[cry3rn]

On Flood v1.0.0-281-gebc8bb7, I still cannot download files at all using Firefox (58.0). Chrome (64.0.3282.119) works just fine though.

[SckyzO]

The same than CRY3rn. Can't download files only on Firefox >58+

[Talanor]

Hello, same error here with the latest github commit to date https://<URL>/api/download?hash=<HASH_VALUE>&files=0 returns a 404 with this error:

{"error":"File not found."}

I'd be glad to give more info in order to see this issue resolved

[SanPilot]

I'm surprised this did not get more attention. (Too many devs using Chrome?)

This is a frontend issue. It appears that newer versions of Firefox ignore the .click() function on elements that are not part of the DOM. (Whether or not this is a bug, I do not know)

Therefore, the element must be appended first to the DOM before it is triggered with the .click() function. Alternatively, location.href can be used to redirect the user-agent. I recommend this approach because I believe it to be simplest. Edit: this won't work because it doesn't support download attribute.

[jfurrow]

Too many devs using Chrome?)

This is true of developers for sure, but also of most users. Firefox usage is pretty low these days, and unfortunately I've done a terrible job of testing in Firefox.

[noraj]

@jfurrow What you just said is absolutely wrong 😄 It's true that the most used browser is unfortunately Google Chrome (even with evident privacy issues) but Mozilla Firefox is still 12% of web browser market use. (see 1 or 2). Before Firefox usage was about 30%, I think this increase in market share for Chrome is artificially high due to mobile progress and the Android dominance. Because every android smartphones have Chrome by default so users won't install Firefox. Anyway Since Firefox 59 (Quantum), Firefox is the faster web browser for desktop and Firefox Developer edition is a great tool. So if we take a look only at desktop market share for people who are IT aware we are maybe about 50% of market share. And that's the point because Flood is a UI for rtorrent that is even not that easy to install, so the target audience is not the worldwide people but IT aware people that are torrenting and will manually install this stuff on their server, so we don't care about global market share but want to know the market share of the target audience of Flood. And in this case Firefox usage is NOT pretty low.

PS : I use only Firefox and I'm blaming you lol 😆 once upon a time web developers were testings their apps on Chrome, Firefox, Safari and IE. Now they are testing only for Chrome and that's a very bad practice. For example you just can't neglect IE because in many enterprise (small and very big ones too) all intranet apps are dev AND actually works only with IE so people in these enterprises are forced to use IE every day and if you develop a website and say "don't care about IE" people at work may have a bad experience browsing your website (but this is not really the problem of Flood but just to give an example).

[jfurrow]

@noraj Sorry, I seem to have struck a nerve, but it's true. Firefox usage is around 5.4%, Chrome is around 57.3% (source).

That said, I should do a better job of testing Flood in these less popular browsers.

[noraj]

@jfurrow For me it's not a low importance nice to have problem but a high importance must have problem. It's like saying we provide support only for windows because it has the highest market shares and f**k other OS.

[SanPilot]

@noraj I don't think that IE and Edge support Flood; they are both missing support for the EventSource API.

[noraj]

@SanPilot That's what I said, Flood don't have to care about IE/Edge because it's not the targeted audience.

[jfurrow]

@noraj Totally agree that Flood should work in all modern browsers.

Honestly Edge support is probably pretty easy too, we can polyfill EventSource.