Cory Benfield added the comment:

Maybe. If we do it we have to apply that timeout to all the socket actions on 
that HTTP connection. This would have the effect of changing the default value 
of the timeout parameter on the HTTPConnection object from 
socket._GLOBAL_DEFAULT_TIMEOUT to whatever value was chosen. We could do this 
for reads only, and avoid applying the timeout to connect() calls, but that's 
kind of weird.

We hit the same problem though: by default, HTTPConnections block indefinitely 
on all socket calls: we'd be changing that default to some finite timeout 
instead. Does that sound like a good way to go?

As for curl's error recovery strategy, I'm pretty sure it just keeps parsing 
the header block. That can definitely be done here. We do have an error 
reporting mechanism as well (sort of): we set the HTTPMessage.status field to 
some error string. We could do that, and continue to parse the header block: 
that's probably the least destructive way to fix this.


Python tracker <>
Python-bugs-list mailing list

Reply via email to