Support proxies

[simon-weber]

Support proxies

[simon-weber]

Note that the current implementation will obey a system-wide proxy (even on Windows).

[simon-weber]

I'm in the middle of the move to requests, and it's surprisingly proxy-unfriendly. It looks like they're actively working on this, so hopefully it doesn't cause a roadblock.

[simon-weber]

I think this is the issue to track: https://github.com/kennethreitz/requests/issues/905.

[aingoppa]

Hi,

I want to capture the traffic of gmusicapi with Fiddler but can do that with current one because of proxy.
Which check-in is the last one to support system-wide proxy?

Thank you,
Kim

[simon-weber]

Oh, sorry about that. The requests folks are slowing making progress, so hopefully this will be supported in the near future.

2013.01.05 was the last version before requests. I wouldn't expect it to work - a lot has changed since then.

If you're looking for protocol details, I've started autogenerating some docs, but the code will be most useful (the relevant section is linked in the docs). You can also intercept the webclient's traffic easily on your own.

[aingoppa]

Thanks for detailed information.

Currently I am working on Google Music Player for Windows Store App. I referenced a Windows port version. It works but rarely I get HTTP response 403 - forbidden for "[GET] https://play.google.com/music/play?u=0&songid=". So I wanted to compare my traffic with gmusicapi to find out any difference.

[simon-weber]

I'm not sure exactly what's causing that, but here are a couple of thoughts:

• what songs do you get 403s on? How were they uploaded? It might be something song-specific
• if after you get the 403, you continually get 403s, you might need to refresh your auth somehow
• it might also be their backend being flaky; have you ever had the same request 403 and then succeed back to back?

[aingoppa]

•what songs do you get 403s on? How were they uploaded? It might be something song-specific
It is regular mp3 and uploaded via official Google Music Manager for Windows. 403 happens not on specific file. I get 403 for the same file which I played Ok many time before. And when I restart, it works Ok again.
•if after you get the 403, you continually get 403s, you might need to refresh your auth somehow
I implemented to re-login after 403. Even the login succeed, still I get 403. But when I just break the app on the debugger and resume in 1 min, sometimes it works with 200.
•it might also be their backend being flaky; have you ever had the same request 403 and then succeed back to back?
Once I have 403, it fails for all my songs and never succeed back to back unless I restart app or sometimes login again.

[simon-weber]

What is the message that you get with the 403? If your auth is invalid, you'd normally get a redirect to Google's login page.

How long does it take before the first error occurs? It sounds like your auth is expiring, but that takes hours, as far as I know.

Sorry I don't have an exact answer for you; it's tough to debug other folk's code =) Here are a few ideas for things to debug:

• what does restarting the app do that logout/login in does not? Perhaps you have state hanging around in your http transport?
• maybe try to diff a back to back 200/403 - does anything change?
• you can always compare your requests against music.google.com with Fiddler

[simon-weber]

Oh, well the error is pretty clear, isn't it? X-Rejected-Reason: ANOTHER_STREAM_BEING_PLAYED means you can't have two clients playing streams at once.

You can see this in action if you log into music.google.com from two different places and try to play from each. I had thought I noted this in the docs, but it turns out I didn't; I'll be sure to fix that.

[aingoppa]

Here is the failed response.

[aingoppa]

You found it! I did not know the response contains reason other than error code. I think there are cases where I did not open 2 players but cannot sure.

One case is when I need to sign out and happened to log in again. Is there logout method available?

Anyway I have a idea how I can handle this case. Thank you so much!

[simon-weber]

Always happy to help =)

Is there logout method available?

In my code, I just drop all the information on the current session (the auth token, various webclient cookies, and xsrf token) - ie, I don't tell the server I'm logging out.

There's definitely a serverside way to invalidate an older session, but I haven't ever looked for it (here's a relevant SO post). From what I've seen, though, if you're using multiple clients the newest one will work and the older ones won't, so it might not be necessary to tell the server.

[simon-weber]

I'd imagine modern versions of requests support this.