Jump to content

uTorrent 2.1 RPC 'invalid request' problem


elmotheelk

Recommended Posts

For my application Transdroid (for Android devices) I use the web UI's JSON RPC. Now everything works fine for 1.8.x and since I added token auth support uTorrent 2.0 works fine as well.

However, I have problems connecting to uTorrent 2.1's web UI. I know this is ALPHA, but still...

Getting the token works fine. It returns the (hidden) HTML and I get the token to construct this GET request:

http://192.168.1.21:8810/gui/?token=gkqjnKJ0DsXISNLPpSJDbNRVoIfOzEnqQJqaTZ-XnJWRdNgVhlLi7koBR0s=&list=1

(of course again with proper credentials)

which has the response 'invalid request'.

It works perfectly fine for uTorrent 1.8.x and 2.0. Also, logging in to and using the web UI itself from my browser works fine. Any ideas?

Link to comment
Share on other sites

I tried putting the token in the url after the list=1, but that didn't work.

I tried to disable token auth temporarily in uTorrent 2.1 and in my app, and everything worked again as expected. So it sure has to do with the token.

Next, I did the following experiment: Open a new browser (no cookie) and go to http://localhost:8080/gui/token.html This requires me to enter the credentials. View the source, copy the token and use it to go to http://localhost:8080/gui/?token=7vK5Bxy6ds7FLG5b_KTleUSp6ZCUT3TFZx5CwZp0vhoDg1hpueRnZqNKS0s=&list=1

This returns a valid JSON string...

Link to comment
Share on other sites

Order of the GET parameters barely matter. And er, WebUI already puts token before list anyway, without issue.

I must ask again, have you tried sniffing the packets to see what's gong on? Could it be that the Android is just caching requests very heavily (including token.html)? Indeed, it doesn't make sense that it's happening only for 2.1, but maybe it's sending slightly different header values that cause the Android to react differently, or something.

Link to comment
Share on other sites

The invalid request error is very specific and only as a few causes.

We can be almost sure that in this case µtorrent isn't accepting the token you are supplying. So something must be going wrong there. Maybe you are adding some hidden character or are encoding improperly.

Like Ultima said: Use a packet sniffer so you can see exactly how the http header looks of the request your app is sending to µtorrent when it tries to retrieve the torrent list. Or if you can't at least enable the logging of webui requests in the r-click menu of the logger tab in µTorrent.

Link to comment
Share on other sites

Thanks for both your responses.

I tried using uRemote (the .NET GUI) and it wasn't able to connect as well. Also, it is persistent on all my systems (Ubuntu/Wine and Vista). I use uTorrent 2.1 build 17687 for testing.

I used tcpdump to snif the packages. Here are the relevant headers (I removed the 0-length packages). Hope you don't mind me pasting those here.

erickok@zwaag:~$ sudo tcpdump -i lo -A -s10000 port 8080

[sudo] password for erickok:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on lo, link-type EN10MB (Ethernet), capture size 10000 bytes

13:44:07.820381 IP zwaag.cs.uu.nl.38856 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:84, ack 1, win 257, options [nop,nop,TS val 9471689 ecr 9471676], length 83

........GET /gui/token.html HTTP/1.1

Host: 131.211.81.197:8080

Connection: Keep-Alive

13:44:07.820533 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38856: Flags [P.], seq 1:160, ack 84, win 256, options [nop,nop,TS val 9471689 ecr 9471689], length 159

........HTTP/1.1 401 Unauthorized

Connection: close

Content-Length: 0

Content-Type: text/html

Cache-Control: no-cache

WWW-Authenticate: Basic realm="uTorrent"

13:44:08.030435 IP zwaag.cs.uu.nl.38857 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:123, ack 1, win 257, options [nop,nop,TS val 9471709 ecr 9471698], length 122

........GET /gui/token.html HTTP/1.1

Host: 131.211.81.197:8080

Connection: Keep-Alive

Authorization: Basic ZXJpYzpDbGlvMTcy

13:44:08.032746 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38857: Flags [P.], seq 1:279, ack 123, win 256, options [nop,nop,TS val 9471710 ecr 9471709], length 278

........HTTP/1.1 200 OK

Connection: keep-alive

Content-Length: 117

Content-Type: text/html

Set-Cookie: GUID=XVMGOIut0hCTJhy7f41W; path=/

Cache-Control: no-cache

<html><div id='token' style='display:none;'>y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=</div></html>

13:44:08.360571 IP zwaag.cs.uu.nl.38858 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:148, ack 1, win 257, options [nop,nop,TS val 9471743 ecr 9471730], length 147

........GET /gui/?token=y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=&list=1 HTTP/1.1

Host: 131.211.81.197:8080

Connection: Keep-Alive

13:44:08.362012 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38858: Flags [P.], seq 1:160, ack 148, win 265, options [nop,nop,TS val 9471743 ecr 9471743], length 159

........HTTP/1.1 401 Unauthorized

Connection: close

Content-Length: 0

Content-Type: text/html

Cache-Control: no-cache

WWW-Authenticate: Basic realm="uTorrent"

13:44:08.578290 IP zwaag.cs.uu.nl.38859 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:187, ack 1, win 257, options [nop,nop,TS val 9471764 ecr 9471753], length 186

....... GET /gui/?token=y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=&list=1 HTTP/1.1

Host: 131.211.81.197:8080

Connection: Keep-Alive

Authorization: Basic ZXJpYzpDbGlvMTcy

13:44:08.579744 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38859: Flags [P.], seq 1:154, ack 187, win 265, options [nop,nop,TS val 9471764 ecr 9471764], length 153

........HTTP/1.1 400 ERROR

Connection: keep-alive

Content-Length: 15

Content-Type: text/html

Set-Cookie: GUID=rjRBmFXS5ZuTfUiF1Fgu; path=/

invalid request

^C

40 packets captured

80 packets received by filter

0 packets dropped by kernel

erickok@zwaag:~$

It seems to me that authentication is denied and, when a retry is send, the 'invalid request' is responded to me.

I use the Java Apache HTTP client that is part of the default Android SDK. This, afaik, doesn't cache pages but it does automatically handle cookies, for example.

Thanks for the help so far.

Link to comment
Share on other sites

Hrm. From my own packet sniffs, it does indeed seem like µTorrent v2.1 is sending different request headers, and even different error codes.

In the past, when it responded with "invalid request", it would return it with a HTTP 300 (which, frankly, isn't even the correct status code, and probably should never have been mentioned/described in the original specifications for token authentication in the first place). Now, µTorrent is correctly returning HTTP 400. I'm not sure if your existing code is reliant on detecting HTTP 300 before deciding to grab a new token, but if so, you might want to change it (checking that the status != 200 and maybe parsing the request body might be a better idea, since AFAIK ony HTTP 200 is sent with successful requests).

As an aside, it seems like µRemote is also trying to detect HTTP 300 as an indicator that a token is required, because after it receives the HTTP 400, it never bothers to request /gui/token.html. Unfortunately, matias has put µRemote development on indefinite hiatus... hopefully he can come back just to fix this bug.

Other than that, µTorrent v2.1 also sets HTTP cookies now, presumably to better support multiple sessions. I doubt that makes a difference though.

When I said I tested an external application without issue with µTorrent v2.1, I was referring to µTorrent Adder. It works fine still, and indeed when I was writing it, I made sure to test that the HTTP status wasn't 200 instead of checking specifically for HTTP 300.

Edit: Ugh, what I wrote is nice and all, but it doesn't seem relevant to your situation, based on your packet sniffs, since you are actively requesting token.html... Only µRemote isn't requesting token.html on error :/ Basically, it looks to me like µRemote's problem is unrelated to yours. So uh, I'm at a loss for ideas right now.

Link to comment
Share on other sites

Hmmz, it looks pretty good.

What I see is:

1) you get token.html but get unauthorized

2) so you get token.html with auth info and get token

3) then you get the list with token but without auth info and get unauthorized

4) so you get the list with token and auth info but now you get invalid request

Now the only thing that is actually wrong here is that normally one would supply the auth info at step 3. It is possibly the token got invalidated because it was used without proper auth info.

I never ran into this issue before but then again browsers keep sending the auth info after it has been accepted once (which is why you actually need to close all browser windows to logout of the webui).

Link to comment
Share on other sites

  • 5 weeks later...

Thanks for your time and replies. This problem is now fixed and indeed it was due to the changes in 2.1. In particular the binding between token and cookie, as explained in http://forum.utorrent.com/viewtopic.php?id=58111

By the way; Transdroid now support token authentication. Would be nice to update this in the Web API app list. Thanks!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...