>>> theurl = 'http://www.garageband.com/mp3cat/.UZCKbS6N4qk/01_Saraenglish.mp3'
>>> if theurl.startswith("http://"):
... theurl = theurl[7:]
... head = theurl[:theurl.find('/')]
... tail = theurl[theurl.find('/'):]
'www.garageband.com'
'/mp3cat/.UZCKbS6N4qk/01_Saraenglish.mp3'
>>> response_code = 0
>>> import httplib
>>> conn = httplib.HTTPConnection(head)
>>> conn.request("HEAD", tail)
>>> res = conn.getresponse()
>>> res.status
>>> response_code = int(res.status)
I guess just double-check everything and try again?
–
–
I recently got this error, in a situation where the method that contained the http request ran successfully once, and then threw this exception (with the status code as an empty string) the second time the method was called (with a different URL). I had a debugging advantage because this is calling my own REST api, so I did some logging on the server side and discovered that the request was never being received. I ultimately figured out that my URL string had a trailing newline character. So make sure that your URLs are stripped of any leading or trailing special characters.
–
If so, perhaps the proxy server is rejecting HEAD requests.
Do you get the same problem if you issue a GET request? If GET works I'd suspect that there is a proxy in your way.
You can see what's going on in more detail by calling conn.set_debuglevel(1) prior to calling conn.request(...).
–
I just found when we get exception httplib.BadStatusLine , is when server goes down and doesn't send any response, so it means web server doesn't even send the http code [1]
[1] http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
–
The problem I had was with multiple requests, but BadStatusLine was only occurring between requests with more then a 5 second interval with a Keep-Alive timeout=5. I'm still uncertain why BadStatusLine was being raised instead of NotConnected. It seems that the connection also defaults to 5 when the header is missing.
The fix was conn.connect() before each request.
I've also encountered this problem.
Accordig to GmailAPI (python), it happens when the server closes the connection before sending a valid respone. Indeed, this only happened to me when my program ran on large DB.
def _read_status(self):
# Initialize with Simple-Response defaults
line = self.fp.readline(_MAXLINE + 1)
if len(line) > _MAXLINE:
raise LineTooLong("header line")
if self.debuglevel > 0:
print "reply:", repr(line)
if not line:
# Presumably, the server closed the connection before
# sending a valid response.
raise BadStatusLine(line)
My solution was to move all the part that establishes the connection with gmail into a function. Then, call this function only before actually sending the email. Before that, the parts incharge of establishing the connection were just 'thrown' in some .py file, and therefore were called at the begining of the run.
We have no clues about what is in your theurl string, and I do not know whether your problem is solved or not (6 years have past and I hope you made it long before), so I just give you one possible reason I met and share it with someone who may find this later.
I have encountered a quite similar problem, in which my code runs quite well on some computers but raises BadStatusLine exceptions sometimes. It is quite annoying just like a ghost.
After careful checked all the possible stituation, I found a 'Content-Length' component was in my request http header. After removeing the component, my code runs well in all computers. Maybe the first part of your theurl contains something like mine, which contradicts the true data length.
I ran into this problem with a python tool I was supporting. It turns out that we had the wrong port info for a service. We were connecting to a server just fine, just not the one we thought we were. It turns out some not-HTTP server was running on that port and returned its own sort of error message. The requests stuff couldn't translate the not-HTTP response into an HTTPResponse, but the first problem it runs into is looking at the first line of the non-HTTP response.
Curiously, we were trying the same thing in curl with no problem, but then someone pointed out that we had typed out the right port by habit instead of the port we had been given and had typed into the code. It took much longer than we'd like to admit that we can't tell the difference between two numbers.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
