Open moham96 opened 5 years ago
moham96
commented
5 years ago @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 1dac502274f2d899098dc7a65536f49a2724eefd
TuxPaper
commented
5 years ago 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.
moham96
commented
5 years ago @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
moham96
commented
5 years ago 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?
ferdnyc
commented
5 years ago 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!??! :open_mouth: )
Attached file (wireshark follow-stream dump): biglybt-transgui-stream.log
TuxPaper
commented
5 years ago 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.
ferdnyc
commented
5 years ago 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.
ferdnyc
commented
5 years ago 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 !
ferdnyc
commented
5 years ago 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.
TuxPaper
commented
5 years ago 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
moham96
commented
5 years ago @TuxPaper after the fix you mentioned transmission-web-control loads fine but I can't add torrents
TuxPaper
commented
5 years ago 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?
moham96
commented
5 years ago @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
This is similar to the #3 which was closed by the OP. The problem is that some frontends that provide webui for transmission are not playing well with Biglybt The webui I tested and didn't work is transmission-web-control
Other improvements related to this issue is we should have the possibility to override the default frontend files, Transmission has multiple ways of doing this:
First, it checks if the environment variable
TRANSMISSION_WEB_HOMEis set then it will use it as a path for the frontend files. then it checks for a user directory~/.local/share/transmission/web/, more specifically it checks for~/.local/share/transmission/web/index.htmland if it exists it will use that path as a frontend. if all these don't exist it will fallback to the default directory (/usr/share/transmission/web/on Linux) I think we should have a similar mechanism to override the default path since copying the files to~/.biglybt/plugins/xmwebui/transmission/webis not very elegent and the files will probably be overwritten when the plugin is updated(haven't tested that), maybe also have a setting in the plugin to specify a custom path.