transmission-remote fails for multiple daemons since 2.4x
-
- Posts: 5
- Joined: Fri Aug 26, 2011 8:24 am
transmission-remote fails for multiple daemons since 2.4x
I have been running multiple instances of transmission-daemon for a while now as mentioned in this post:
viewtopic.php?f=8&t=12092
The web inteface works nicely for each instance and downloads work fine, however transmission-remote no longer works except on the default instance.
I used nginx to proxy transmission through SSL.
e.g.
https://website - default instance port 9091
https://website/subsite1 - second instance port 9092
https://website/subsite2 - third instance port 9093
https://website/subsite3 - fourth instance on port 9094
If I run the following command on the default instance it works as expected:
transmission-remote localhost:9091/transmission --auth <user>:<pass> --list
However any other instance I run fails with Unexpected response: <h1>301: Moved Permanently</h1>
i.e. transmission-remote localhost:9092/subsite1/transmission --auth <user>:<pass> --list
Again as mentioned this worked perfectly until recently when I updated to 2.4x
Anyone know of what changes have caused this response?
Thanks
viewtopic.php?f=8&t=12092
The web inteface works nicely for each instance and downloads work fine, however transmission-remote no longer works except on the default instance.
I used nginx to proxy transmission through SSL.
e.g.
https://website - default instance port 9091
https://website/subsite1 - second instance port 9092
https://website/subsite2 - third instance port 9093
https://website/subsite3 - fourth instance on port 9094
If I run the following command on the default instance it works as expected:
transmission-remote localhost:9091/transmission --auth <user>:<pass> --list
However any other instance I run fails with Unexpected response: <h1>301: Moved Permanently</h1>
i.e. transmission-remote localhost:9092/subsite1/transmission --auth <user>:<pass> --list
Again as mentioned this worked perfectly until recently when I updated to 2.4x
Anyone know of what changes have caused this response?
Thanks
Re: transmission-remote fails for multiple daemons since 2.4
In settings.json, the line:
is probably what you need to change for each instance.
Code: Select all
"rpc-url": "/transmission/",
-
- Posts: 5
- Joined: Fri Aug 26, 2011 8:24 am
Re: transmission-remote fails for multiple daemons since 2.4
Hi rb07,
Thanks for your reply.
I already have the "rpc-url" field updated as the following, but still doesn't work:
"rpc-url": "/subsite1/transmission/"
As mentioned it was working well in previous versions.
Thanks for your help.
Thanks for your reply.
I already have the "rpc-url" field updated as the following, but still doesn't work:
"rpc-url": "/subsite1/transmission/"
As mentioned it was working well in previous versions.
Thanks for your help.
-
- Posts: 5
- Joined: Fri Aug 26, 2011 8:24 am
Re: transmission-remote fails for multiple daemons since 2.4
Further information ...
Looking at the debug information it appears that transmission-remote picks up the use of an alternative port e.g. 9092, but then seems to hardcode the RPC url to http://localhost:9092/transmission/rpc
i.e. it seems to ignore any alternative URL settings specified e.g. /subsite1/transmission
It therefore goes to an invalid URL and gets the mentioned 301 response.
Looking at the debug information it appears that transmission-remote picks up the use of an alternative port e.g. 9092, but then seems to hardcode the RPC url to http://localhost:9092/transmission/rpc
i.e. it seems to ignore any alternative URL settings specified e.g. /subsite1/transmission
It therefore goes to an invalid URL and gets the mentioned 301 response.
-
- Posts: 4
- Joined: Tue Sep 23, 2014 10:04 am
Re: transmission-remote fails for multiple daemons since 2.4
For information, this bug - exactly as described above - still exists in 2.52.
Code: Select all
alphabeti# transmission-remote -l
Unexpected response: <h1>301: Moved Permanently</h1>pplication/x-www-form-urlencoded
alphabeti# grep rpc-url /etc/transmission1-daemon/settings.json
"rpc-url": "/transmission1/",
alphabeti#
Re: transmission-remote fails for multiple daemons since 2.4
Its not a bug, transmission-remote never supported redirection.
If you are trying to do what the original poster was trying to do, then you're doing it wrong: a redirection is not a proxy (and a proxy doesn't respond with a redirection).
You could configure a real proxy (i.e. its not the software name or description, its the configuration), or you could patch transmission-remote adding the functionality to follow redirections:
Only the last libcurl option was added. Untested.
If you are trying to do what the original poster was trying to do, then you're doing it wrong: a redirection is not a proxy (and a proxy doesn't respond with a redirection).
You could configure a real proxy (i.e. its not the software name or description, its the configuration), or you could patch transmission-remote adding the functionality to follow redirections:
Code: Select all
static int
flush (const char * rpcurl, tr_variant ** benc)
{
...
curl_easy_setopt (curl, CURLOPT_TIMEOUT, getTimeoutSecs (json));
curl_easy_setopt (curl, CURLOPT_FOLLOWLOCATION, 1L);
...
-
- Posts: 4
- Joined: Tue Sep 23, 2014 10:04 am
Re: transmission-remote fails for multiple daemons since 2.4
Re "transmission-remote never supported redirection", understood, but I am not knowingly requesting redirection, I have simply modified rpc-url in the daemon's config file. If I want to use transmission-remote to communicate with this daemon, how should I do it?
If I should be able to do this, then there is bug, because it is not possible (e.g. change rpc-url to "/foo/", restart transmission-daemon, try communicating with it using transmission-remote).
If I should not be able to do this, then could this be made more explicit in the documention? (e.g. "WARNING: if you modify rpc-url then you will not be able to use transmission-remote to communicate with the daemon"). IMHO if rpc-url is configurable then that invites people to make their daemon incompatible with transmission-remote.
If I should be able to do this, then there is bug, because it is not possible (e.g. change rpc-url to "/foo/", restart transmission-daemon, try communicating with it using transmission-remote).
If I should not be able to do this, then could this be made more explicit in the documention? (e.g. "WARNING: if you modify rpc-url then you will not be able to use transmission-remote to communicate with the daemon"). IMHO if rpc-url is configurable then that invites people to make their daemon incompatible with transmission-remote.
Re: transmission-remote fails for multiple daemons since 2.4
First point: If your report is not about multiple daemons, like the title on this thread says, then don't write on this thread. If you were using a proxy you wouldn't need what is described below.
Second point: stop assuming its a bug just because you can't make it work (i.e. it works, I just tested it again).
The only evidence you showed was a simple command: "transmission-remote -l", and a line in the configuration: '"rpc-url": "/transmission1/",' There's an error right there, can you see it?
The command "transmission-remote -l" is using the defaults:
Looking at transmission-remote's help gives you a hint about how to do it (except that the last slash shouldn't be used):
On my test, I get:
Second point: stop assuming its a bug just because you can't make it work (i.e. it works, I just tested it again).
The only evidence you showed was a simple command: "transmission-remote -l", and a line in the configuration: '"rpc-url": "/transmission1/",' There's an error right there, can you see it?
The command "transmission-remote -l" is using the defaults:
- host = localhost
- port = 9091
- url = <host>:<port>/transmission/rpc/
Looking at transmission-remote's help gives you a hint about how to do it (except that the last slash shouldn't be used):
Code: Select all
$ transmission-remote -h
transmission-remote 2.84 (14307)
A fast and easy BitTorrent client
http://www.transmissionbt.com/
Usage: transmission-remote [host] [options]
transmission-remote [port] [options]
transmission-remote [host:port] [options]
transmission-remote [http(s?)://host:port/transmission/] [options]
...
Code: Select all
$ transmission-remote http://localhost:9091/t1 -l
ID Done Have ETA Up Down Ratio Status Name
Sum: None 0.0 0.0
-
- Posts: 4
- Joined: Tue Sep 23, 2014 10:04 am
Re: transmission-remote fails for multiple daemons since 2.4
I am using multiple daemons running on one system, which is why I was looking at rpc-url, and how I came across this thread.
Re "url = <host>:<port>/transmission/rpc/", yes, that was the source of my confusion! The OP said he used "transmission-remote localhost:9091/transmission". So, like me, he must have thought that transmission-remote was using the path component of the URL he specified (i.e. "localhost:9091/transmission") but from what you say (i.e ".../transmission/rpc/" rather than .../<path-component>") then it is now clear to me that transmission-remote always uses /transmission/rpc, regardless of what we put on the command line. Thanks for the clarification!
The OP said:
Just in case other people come across this: multiple instances will only work with transmission-remote if you use different rpc-port values for each instance but identical and default rpc-url values.
Re "url = <host>:<port>/transmission/rpc/", yes, that was the source of my confusion! The OP said he used "transmission-remote localhost:9091/transmission". So, like me, he must have thought that transmission-remote was using the path component of the URL he specified (i.e. "localhost:9091/transmission") but from what you say (i.e ".../transmission/rpc/" rather than .../<path-component>") then it is now clear to me that transmission-remote always uses /transmission/rpc, regardless of what we put on the command line. Thanks for the clarification!
The OP said:
which I interpreted as meaning that his specification of <path-component> in the URL had worked at some time in the past but doesn't any longer. Okay, so there has been a change in behaviour, but that's allowedI have been running multiple instances of transmission-daemon for a while now ... however transmission-remote no longer works except on the default instance.
Just in case other people come across this: multiple instances will only work with transmission-remote if you use different rpc-port values for each instance but identical and default rpc-url values.
Re: transmission-remote fails for multiple daemons since 2.4
None of what you say is true. Some parts don't even make sense, how do you intend to run multiple instances of the daemon if all use the same port? The original post implied (not very well and the report is very poorly written) that using a proxy took care of directing the traffic to the different daemons, and that is completely different from what you have described.
Did you see my example?
The URL doesn't have to be the default, and I showed it. You are still assuming that transmission-remote is somehow going to guess what you don't tell it.
Did you see my example?
The URL doesn't have to be the default, and I showed it. You are still assuming that transmission-remote is somehow going to guess what you don't tell it.
-
- Posts: 4
- Joined: Tue Sep 23, 2014 10:04 am