Base64 encoding of metadata to send to daemon RPC

[glennpow]

I'm trying to write a tool that will send torrent file metainfo to the daemon via RPC, but I can't seem to figure out the correct method to encode the metainfo.
I am using Javascript and can take advantage of Mozilla's window.btoa function, which base64 encodes a string. However, if I pass in the raw contents of the torrent file, I get an error stating that an incorrect character exists in the string trying to be encoded. So I have tried to first call escape() on the metainfo (or also to first UTF8 encode the metainfo) before sending it to the btoa() function, which does allow the encoding to succeed. However, then when I pass this encoded string to the RPC, I get back an error from the daemon: "invalid or corrupt torrent file".

My tool works just fine if I simply send the torrent URL to the RPC, but I'm trying to get the metainfo strategy to work as well for sites requiring authentication.

Does anyone know what the correct procedure to encode the metainfo is? Also, the metainfo is the ENTIRE contents of the torrent file, correct?

[Jordan]

Hi glennpow,

You may want to try what lots of other RPC programmers do, which is to use "transmission-remote --debug" as a point of reference. In this case, comparing the output of "transmission-remote --debug --add filename" to your own RPC request may shed some light on what's going on...

[glennpow]

Unfortunately, I'm not sure if this will help me. Firstly, I'm not sure if transmission-remote can be passed the raw base64-encoded metainfo data. I think you can only pass in the filename (or URL) of the torrent file. This, of course, works just fine on my machine, but I'm trying to make use of the metainfo method of the RPC in order to get around the problem of website authentication. If I'm wrong, and the transmission-remote command can in fact take the encoded metainfo, then please let me know. But even if this is the case, I'm not sure sure it can help me. I'm fairly certain the debug will simply tell me that the format of the metainfo is incorrect, which it naturally will be if the base64-encoding was processed incorrectly.
I have now tried somewhere around 10 different methods to encode the data, and none of them have worked. The simplest is to perform the following:

Code: Select all

encode64: function(input) {
  return window.btoa(unescape(encodeURIComponent(input)));
}

Can anyone see a problem with this? I thought the unescape and encodeURIComponent functions would do the UTF-8 conversion, and the btoa function would do the encoding. The resulting string does look 64-encoded, but fails with transmission.
Has anyone used javascript to do the encoding necessary for transmission RPC?

[Jordan]

Unfortunately, I'm not sure if this will help me. Firstly, I'm not sure if transmission-remote can be passed the raw base64-encoded metainfo data. I think you can only pass in the filename (or URL) of the torrent file.

Yes, it can, as "transmission-remote --debug --add filename" will show you. Then you can compare its input and your own RPC message to see what differences there are.

Here is a pastebin of such a session adding the torrent "Sita Sings the Blues" from legaltorrents.com: http://pastebin.ca/1750053

$ ./transmission-remote --debug --add ~/Downloads/*Sita*torrent

posting:

--------

{"arguments":{"metainfo":"ZDg6YW5ub3VuY2U0MjpodHRwOi8vZGVuaXMuc3RhbGtlci5oM3EuY29tOjY5Njkv\nYW5ub3VuY2UxMzphbm5vdW5jZS1saXN0bGw0MjpodHRwOi8vZGVuaXMuc3RhbGtl\nci5oM3EuY29tOjY5NjkvYW5ub3VuY2VlbDMwOmh0dHA6Ly90cmFja2VyLnBycS50\nby9hbm5vdW5jZWVsNDM6aHR0cDovL3RyYWNrZXIudG9ycmVudGZyLm9yZzo1NjY2\nNi9hbm5vdW5jZWVsNDI6aHR0cDovL3d3dy50b3JyZW50c25pcGUuaW5mbzoyNzAx\nL2Fubm91bmNlZWwzNTpodHRwOi8vd3d3LnN1bW90cmFja2VyLmNvbS9hbm5vdW5j\nZWVsNDU6aHR0cDovL29wZW4udHJhY2tlci50aGVwaXJhdGViYXkub3
[..snipped for terseness in the forums...]+fn80z1j5iKLYPfznnskU2n4FZ5n7AOJUBHTaAZ9OzzS4IWYx5uKBhEYI\n3wOlKRFMwEeoJ6mHAdv6eoepLx5FgBWJr0VMUw99QiAvJbbam5C8du4ICtlsLHX3\nFfMvb8fzJrskWm9AOEbpH2+v5WgdYHh+6VGuLzah6vfyO1NPuQg+3ixVpL2ky1mP\nKvMmISDRO0Fa+FNoBuf3qzpi41PUHE+zhcoKwscXu9mmDVDm1wo2hAJmUo3eOtZ5\niFtKt8hhR41AeyBo6cowGm4wSIeEnkaq\/QrG9kHH6ic8Olq\/g1jEPvcRjzGTsb4b\n6mFACU+sJvJ4wlkWV57rtifXnKz+dL3k92QuTjYc2YIcDeRlODp1cmwtbGlzdGw4\nNjpodHRwOi8vd3d3LmFyY2hpdmUub3JnL2Rvd25sb2FkL1NpdGFfU2luZ3NfdGhl\nX0JsdWVzL1NpdGFfU2luZ3NfdGhlX0JsdWVzX0RWRF9OVFNDLmltZ2Vl\n"},"method":"torrent-add"}

--------

* Couldn't find host localhost in the .netrc file; using defaults
* About to connect() to localhost port 9091 (#0)
* Trying ::1... * Connection refused
* Trying 127.0.0.1... * connected
* Connected to localhost (127.0.0.1) port 9091 (#0)
> POST /transmission/rpc HTTP/1.1

User-Agent: transmission-remote/1.76+ (9920)
Host: localhost:9091
Accept: */*
Accept-Encoding: deflate, gzip
X-Transmission-Session-Id: mBjkgGo87VHidnWQz0JuMULdIBzmW3LTmaPWTTxMLWN5MNA6
Content-Length: 124845
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

* Done waiting for 100-continue

< HTTP/1.1 200 OK
< Server: Transmission
< Content-Encoding: deflate
< Content-Type: application/json; charset=UTF-8
< Date: Wed, 13 Jan 2010 20:06:34 GMT
< Content-Length: 138
<
* Connection #0 to host localhost left intact
got response (len 159):

--------

{"arguments":{"torrent-added":{"hashString":"2c734949e128fc498e40efbce728b5d2d84e4a2b","id":1,"name":"Sita_Sings_the_Blues_DVD_NTSC.img"}},"result":"success"}

--------

localhost:9091 responded: "success"

* Closing connection #0

I thought the unescape and encodeURIComponent functions would do the UTF-8 conversion, and the btoa function would do the encoding. The resulting string does look 64-encoded, but fails with transmission.

I know there are people who have used Javascript to base64ize data before passing it to Transmission, but I haven't done it firsthand and don't know where the problem lies in that code snippet, sorry. Maybe Google would help?