Grooveshark早期关闭连接(httplib.BadStatusLine)

时间:2012-06-15 23:06:52

标签: python httplib2 grooveshark

我正在尝试连接到groovehark。因为这个python是我选择的语言。但我撞到了一堵砖墙。看来groovehark最近改变了部分协议,或者我可能已经达到了python的限制。

我和github的JackTheRipper51“一起”工作,他为groovehark创建了这个库:https://github.com/jacktheripper51/groove-dl 它实际上不是一个图书馆,但我很快就被记录为一个图书馆。

本周早些时候,它运行良好,我能够将它用于我的项目。但是2天前它开始在getToken函数上失败了,httplib开始返回httplib.BadStatusLine: '',我的研究意味着服务器提前关闭了连接。

从这项研究开始,我开始研究groovehark的javascript和flash源码,但这并没有带来任何有价值的东西。所以我做了任何理智的人花了5个小时查看反编译的动作脚本,而没有在事先编写过一行,并将其归咎于grooveharks服务器。

具体来说,我认为groovehark可能会拒绝具有Connection: close标题的连接。因此,我决定在Chrome的REST Console扩展程序中进行测试。

我让python脚本转储它正在编码的json,然后我将它粘贴到Rest Console,点击POST,它返回正常,带有预期的数据。我现在确信我是不对的。

我的下一步是在httplib2中编码(因为它支持Connection: keep-alive),但问题仍然存在。

我已经在wireshark中进行了测试(在https中删除了SSL,它确实发送了Connection: keep-alive,这会导致groovehark响应,但是https required

我只修改了代码的一小部分。

完全改变了getToken()

def getToken():
    global staticHeader, _token
    post = {}
    post["parameters"] = {}
    post["parameters"]["secretKey"] = hashlib.md5(staticHeader["session"]).hexdigest()
    post["method"] = "getCommunicationToken"
    post["header"] = staticHeader
    post["header"]["client"] = "htmlshark"
    post["header"]["clientRevision"] = "20120312"
    header = {"User-Agent": _useragent, "Referer": _referer, "Content-Type":"application/json", "Cookie":"PHPSESSID=" + staticHeader["session"], "Connection":"keep-alive"}
    response, content = http.request("https://grooveshark.com/more.php?getCommunicationToken", "POST" ,body = json.JSONEncoder().encode(post), headers = header)
    print response
    #_token = json.JSONDecoder().decode(gzip.GzipFile(fileobj=(StringIO.StringIO(conn.getresponse().read()))).read())["result"]
    #print _token

我添加了httplib2初始化的内容:

http = httplib2.Http()

我导入了httplib2:

import httplib, httplib2

我还重命名了json构造函数,因为我想要更具描述性。

完整的追溯是:

Traceback (most recent call last):
  File "C:\Users\Delusional Logic\Documents\GitHub\groove-dl\python\groove.py", line 141, in <module>
    getToken()
  File "C:\Users\Delusional Logic\Documents\GitHub\groove-dl\python\groove.py", line 51, in getToken
    response, content = http.request("https://grooveshark.com/more.php?getCommunicationToken", "POST" ,body = json.JSONEncoder().encode(post), headers = header)
  File "C:\Python27\lib\site-packages\httplib2-0.7.4-py2.7.egg\httplib2\__init__.py", line 1544, in request
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
  File "C:\Python27\lib\site-packages\httplib2-0.7.4-py2.7.egg\httplib2\__init__.py", line 1294, in _request
    (response, content) = self._conn_request(conn, request_uri, method, body, headers)
  File "C:\Python27\lib\site-packages\httplib2-0.7.4-py2.7.egg\httplib2\__init__.py", line 1264, in _conn_request
    response = conn.getresponse()
  File "C:\Python27\lib\httplib.py", line 1027, in getresponse
    response.begin()
  File "C:\Python27\lib\httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "C:\Python27\lib\httplib.py", line 371, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine: ''

导致BadStatusLine的原因是什么,以及如何解决它。

PS我知道他们在这次爆发前一天有8小时的会议,我打赌你这是在议程上。

更新:JackTheRipper51告诉我,无论你发送什么,这都发生在对groovehark.com/more.php的所有ssl请求中。这让我相信它是蟒蛇在我们身上耍花招。

更新2:

JackTheRipper51刚告诉我这确实是蟒蛇。这是他的帖子:

  

我根本不需要C.准备好被激怒。一个简单的

curl -H "Content-Type: text/plain" -d "@jsontest" "https://grooveshark.com/more.php?getCommunicationToken" -v on a linux
  

盒子给了我一个代币...... jsontest在这里

{"header":{"client":"mobileshark","clientRevision":"20120227","privacy":0,"country":{"ID":63,"CC1":4611686018427388000,"CC2":0,"CC3":0,"CC4":0,"DMA":0,"IPR":0},"uuid":"BF5D03EE-91BB-40C9-BE7B-11FD43CAF0F0","session":"1d9989644c5eba85958d675b421fb0ac"},"method":"getCommunicationToken","parameters":{"secretKey":"230147db390cf31fc3b8008e85f8a7f1"}}
  

即使json在语法上不正确,它总是返回   至少一些标题!一直都是Python ......

剩下的唯一问题是为什么python会这样做?

1 个答案:

答案 0 :(得分:1)

问题已“解决”,或已找到原因。

JackTheRipper将错误提交给python,在那里他们确认ssl确实存在问题,更具体地说是openssl 0.9.8,这导致连接超时。

错误报告: http://bugs.python.org/issue15082