compatibility with Transmission's RPC API + other improvements about biglybt-plugin-xmwebui HOT 13 OPEN

New plugin has just been released with a config option for setting a path to an alternate web ui. Also fixed a few issues (not the last one you mentioned). Using the alternate web ui path config should be more stable, since it uses the standard /transmission/web URL path

from biglybt-plugin-xmwebui.

@TuxPaper
looking at the requests that transmission-web-control is making it seems it sends an empty POST request which might be causing the problem.
the request is to the /rpc
and the response from the plugin is
d14:failure reason16:'method' missinge
so the plugin doesn't accept a POST request without a method parameter
probably related to 1dac502

from biglybt-plugin-xmwebui.

Thanks for digging into it. The commit you reference causes a 409 response on empty POSTs that don't send along the "X-Transmission-Session-Id". However, after that, I'm pretty sure it sends that failure reason for empty posts. The 409 is part of the spec, and usually makes the front end store the session-id for future rpc calls (one's with methods..)

Maybe transmission-web-control is calling the RPC with no post data after it receives the session id, and then dies. I'm not sure what response it's actually expecting, but I'll look into it.

from biglybt-plugin-xmwebui.

@TuxPaper Ok I think I found the problem, the issue is that the plugin only return 409 to empty POSTs if the call is to /transmission/rpc, for some reason transmission-web-control is not calling /transmission/rpc but it calls /rpc, I used an http debugger/proxy to modify the request from /rpc/ to /transmission/rpc and it worked( haven't fully tested the frontend but at least the torrents and settings are showing).
I don't understand why the plugin is only sending 409 on /transmission/rpc since the response.setReplyStatus( 409 ); is enclosed in an if statement that checks for /tansmission/rpc and /rpc

from biglybt-plugin-xmwebui.

A workaround for now is to change the rpcpath in here:
https://github.com/ronggang/transmission-web-control/blob/9cda1f69b1b9501462d103852df3e7b441400a21/src/tr-web-control/script/min/transmission.min.js#L1

from ../rpc to /transmission/rpc

This doesn't break compatibility of the frontend with transmission client, should we send a PR to change it in the frontend? or should this get resolved in biglybt?

from biglybt-plugin-xmwebui.

I gave transmission-remote-gui (AKA transgui) a whirl, against the xmwebui instance I've been using for quite some time via direct HTTP and also with a browser "add-torrent" type extension.

Unfortunately, any attempt to connect to BiglyBT (with the proper credentials set in the transgui preferences) results in an error dialog containing:

error: invalid core parameter: Max Upload Speed Seeding KBs

Tracing the session via wireshark, that's pretty much exactly the contents of BiglyBT's reply to the connection requests. Here's a lightly-sanitized "Follow HTTP Stream" view of one session, two such requests made, same response. I've broken the two streams apart based on the wireshark color coding, but it's a simple request-response-request-response flow.

(Also, random observation: X-Transmission-Session-Id=0x1.e1423f96bb28p-7 ...is that value in scientific notation!??! 😮 )

Attached file (wireshark follow-stream dump): biglybt-transgui-stream.log

POST /transmission/rpc HTTP/1.1
Host: aaa.bbb.ccc.net:port
Authorization: Basic __SECRET__=
Keep-Alive: 300
Connection: keep-alive
Cookie: vuze_pairing_sc=____BIGGER_DAMN_SECRET____; X-Transmission-Session-Id=0x1.e1423f96bb28p-7
User-Agent: Mozilla/4.0 (compatible; Synapse)
Content-Type: application/json; charset=UTF-8
Content-Length: 28

{ "method" : "session-get" }

HTTP/1.1 200 OK
Last-Modified: Fri, 31 Aug 2018 17:07:31 GMT
Expires: Fri, 31 Aug 2018 17:07:31 GMT
Set-Cookie: X-Transmission-Session-Id=0x1.e1423f96bb28p-7; path=/; HttpOnly
X-Transmission-Session-Id: 0x1.e1423f96bb28p-7
Server: BiglyBT 1.6.0.1_B07
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
Content-Length: 73

{"result":"error: invalid core parameter: Max Upload Speed Seeding KBs"}

POST /transmission/rpc HTTP/1.1
Host: aaa.bbb.ccc.net:port
Authorization: Basic __SECRET__=
Keep-Alive: 300
Connection: keep-alive
Cookie: vuze_pairing_sc=____BIGGER_DAMN_SECRET____; X-Transmission-Session-Id=0x1.e1423f96bb28p-7
User-Agent: Mozilla/4.0 (compatible; Synapse)
Content-Type: application/json; charset=UTF-8
Content-Length: 28

{ "method" : "session-get" }

HTTP/1.1 200 OK
Last-Modified: Fri, 31 Aug 2018 17:07:45 GMT
Expires: Fri, 31 Aug 2018 17:07:45 GMT
Set-Cookie: X-Transmission-Session-Id=0x1.e1423f96bb28p-7; path=/; HttpOnly
X-Transmission-Session-Id: 0x1.e1423f96bb28p-7
Server: BiglyBT 1.6.0.1_B07
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
Content-Length: 73

{"result":"error: invalid core parameter: Max Upload Speed Seeding KBs"}

from biglybt-plugin-xmwebui.

I'm currently away from the office, but I can quickly answer your latest post. It looks like the "invalid core parameter" error is due to the use of the Speed Limit Manager, most likely the "Seeding only limit enabled" setting(s). This is a bug on my end, and I will fix it when I get back. However, I'm guessing turning off the seeding only limit setting(s) will move you one step closer to a working webui

And yes, I'll look into the ../rpc to /transmission/rpc problem. I should be able to fix it on our end too.

from biglybt-plugin-xmwebui.

It looks like the "invalid core parameter" error is due to the use of the Speed Limit Manager, most likely the "Seeding only limit enabled" setting(s).

@TuxPaper – Appreciate the update! I only had a few minutes to quickly peruse my config before running out the door, but when you say "Speed Limit Manager", I'm not clear what that's referring to.

If it's the name of a plugin, I don't think I even have it INSTALLED.

I do have limits set in Options > Transfer, but they're entirely static. Everything below Options > Transfer > Auto-Speed is disabled.

from biglybt-plugin-xmwebui.

Indeed, I switched off "Alternate rate when only seeding" in Options > Transfer, and transgui immediately connected to BiglyBT as a remote interface. So, it was just that simple.

I don't really need that preference, so for the moment I'm fine with leaving it switched off indefinitely while I explore transgui. Thanks for the pointer, @TuxPaper !

from biglybt-plugin-xmwebui.

One thing I'm noticing with transgui, fairly minor really: It's listing all torrents with the "Scrape Disabled" tracker-status in its error bin. So I've got 39 torrents listed as "Error" in transgui, despite having 0 with the Error tag in BiglyBT. I don't know if that's something that can be controlled from the sever side, but it'd be cool if those misreported error states could be cleared up.

from biglybt-plugin-xmwebui.

@TuxPaper after the fix you mentioned transmission-web-control loads fine but I can't add torrents

from biglybt-plugin-xmwebui.

hmm, I'm using transmission-web-control-1.6.0-beta2 and was able to add a .torrent file and an URL. :/
Which way did you try?

from biglybt-plugin-xmwebui.

@TuxPaper I don't know why but I had to remove my ~/.biglybt directory and start fresh to get it working, otherwise, some requests like adding torrents or stopping all torrents will just return 401 error code while other requests like getting the stats or settings were working correctly, very strange.
Thank you now everything works fine

from biglybt-plugin-xmwebui.