Use HTML5's FileReader to upload .torrent files

[jordan]

We should use FileReader? when adding torrents. The new process would be to use FileReader? to load the file and convert it to base64, then send it to the server with the standard 'torrent-add' method.

This would be good in at least two ways:

1. It'll allow us to stop bundling the jquery.form.js module

2. It'll allow us to remove the undocumented POST-to-/upload/ hack from libtransmission/rpc-server.c.

The post-to-/UPLOAD/ hack will be marked for removal in the RPC documentation, but kept around for a few months in case any third party clients are using it.

[jordan]

r14005: use FormData? and jQuery.ajax() to upload .torrent files

[JJTagy]

This breaks IE9 and below users as FormData? is not supported until IE10.

[jordan]

IMO this is okay. FormData's been supported in FF, Chrome and Safari for 3 years. Opera supports it too, and IE10 has been out for 6 months.

[JJTagy]

Of course you think it is okay - because you don't use it. If the goal is to force upgrade or not support "older" web browsers, why do we have things like <!--[if IE 8]> still in the source?

[JJTagy]

IE10 is still in Beta.

[killemov]

I have used the base64 encoding option for Shift. Will that keep functioning without change?

{
  "method":"torrent-add",
  "arguments": {
    "download-dir":"/data/downloads",
    "paused":false,
    "metainfo":"base64encodeddata"
  }
}

​https://github.com/killemov/Shift/blob/master/shift.js#L2092 ​https://github.com/killemov/Shift/blob/master/shift.js#L2127

[jordan]

killemov: this doesn't affect the torrent-add method at all. This is about using PostData? to read a .torrent file from disk and send it to the server without the javascript code having firsthand access to it.

I was under the impression that browsers' security models wouldn't let us read arbitrary files from disk s.t. we could convert them to base64 and upload them with torrent-add. If you're saying this is possible, then we can get rid of this special case code altogether and use torrent-add... am I understanding you correctly?

[jordan]

a follow-up to the previous comment and how shift loads files: looks like FileReader? support wasn't fully supported in IE until IE 10 either... :)

​http://caniuse.com/filereader

[jordan]

...even though it's no nicer for backwards compatability than PostData?, it's still much cleaner wrt letting us get rid of the POST /upload hack. Thanks killemov!

[jordan]

r14025 "(web) #5290 'Use HTML5's FileReader? to upload .torrent files': done"

[KyleK]

It seems to me this broke the uploading of a torrent via URL. Adding a URL to the File Upload dialog and pressing "Upload" closes the dialog, but the torrent does not appear. There is no entry in the log file, and Web Inspector doesn't report any problems either.

[JJTagy]

Installed IE10 and checked both versions (r14025 and r14005) and uploading via URL broken in both. Running on r14004 until this patch is fixed or reverted.

[jordan]

Reopening based on KyleK's comment that this breaks uploading torrents via URL

[killemov]

Urls need different processing: ​https://github.com/killemov/Shift/blob/master/shift.js#L2162

Please hand out kudos on github. :P

[KyleK]

I tried fixing the URL issue, but I'm just not firm enough in JavaScript?. Can anyone hack together a quick fix for this? It's really difficult adding new torrents to Transmission, especially if you only have a magnet URI, and are on a mobile device.

[TuxPaper]

Add back in the old #torrent_upload_url code

[TuxPaper]

I'm no expert, but adding back in the old torrent_upload_url code seems to work for me (see attached patch)

[jordan]

That helps, but the download-dir argument gets lost when adding by URL if we do that.

r14061 fixes it, though at the cost of some code duplication.