Skimming through the code, the only place where we can reasonably block is inside HTTPConnection._send_output(), when the data is actually sent to the socket.
What probably happens is the following:
- connect() call succeeded, we have an established TCP connection
- before request() is called - or in the middle of the sending - the host at the other host goes down in brutal way, so that we don't receive a FIN/RST: the TCP stack has no clue that the remote host went down
- we keep sending data through the socket, until the socket write buffer fills up, and then, since httplib uses blocking sockets by default, we block on the send() call

Now, depending on the TCP stack setting, after a given number of retries the stack will decide the other host went down, and return an error. But this can take a long time (under Linux, it's set by net.ipv4.tcp_retries2 sysctl by default to 30 minutes).
The only thing that surprises me here is that when the host is back online, we should get a RST, but it depends on the OS, the timeouts, maybe there's a statefull firewall, etc.

So I'd say it's not a httplib issue here, it's just a standard behaviour of a TCP connection when an host goes down.

Note that the solution is simply to use non-blocking socket, and it's already implemented. Heck, it's even documented actually:

class httplib.HTTPConnection(host[, port[, strict[, timeout[, source_address]]]])
If the optional timeout parameter is given, blocking operations (like connection attempts) will timeout after that many seconds (if it is not given, the global default timeout setting is used).

So for me it's not an issue, but given the lack of infos, maybe I got it completely wrong ;-)