| msg102186 - (view) |
Author: David Andrzejewski (dandrzejewski) |
Date: 2010-04-02 18:58 |
| Python 2.6.4, Windows XP. If you run the following code: import httplib http_connection = httplib.HTTPConnection("192.168.192.196") http_connection.request("GET", "/") http_connection.sock.settimeout(20) response = http_connection.getresponse() data = response.read() http_connection.close() And then run a netstat -a, you'll see that the connection is no longer established (it'll have a status of TIME_WAIT or something along those lines). However, if you run the following code: import httplib http_connection = httplib.HTTPSConnection("192.168.192.196") http_connection.request("GET", "/") http_connection.sock.settimeout(20) response = http_connection.getresponse() data = response.read() http_connection.close() And run a netstat, the connection will still be in the ESTABLISHED state. The connection does not end for several minutes (or when you terminate the program). I can get the connection to end when I want it by doing a del on the connection object and then manually running garbage collection - although that seems a bit wonky. I'm not really sure what all the differences are between HTTPConnection and HTTPSConnection, but it seems like they should both behave the same way in this regard. |
|
|
| msg102471 - (view) |
Author: David Andrzejewski (dandrzejewski) |
Date: 2010-04-06 16:08 |
| Now, it turns out that if you send the HTTP "Connection: close" header, the connection does close at the end (because the server closes it). Still, it seems like this should behave the same regardless of whether it's HTTPConnection or HTTPSConnection. |
|
|
| msg111083 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2010-07-21 16:19 |
| fixed a similar issue (the timeout of the initial socket was not passed to the ssl socket). Can someone test again with a recent py3k build? |
|
|
| msg111118 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-07-21 20:53 |
| Works fine here under Linux, with 3.2, 2.6 and 2.7. HTTPS connections actually get recycled quicker than plain HTTP ones. Please note that your results could also depend on the behaviour of the target server. I tested against http://linuxfr.org. |
|
|
| msg111119 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-07-21 20:57 |
| Works fine under a Windows XP VM too. |
|
|
| msg118117 - (view) |
Author: PoltoS (PoltoS) |
Date: 2010-10-07 16:13 |
| I've the with module ssl. If I do sock.close() (sock is instance of ssl.SSLSocket), the connection is not closed: I see it as Established in netstat and nothing is sent over network: tcpdump show nothing going thru the network. Python 2.6.5 Linux Ubuntu |
|
|
| msg118119 - (view) |
Author: PoltoS (PoltoS) |
Date: 2010-10-07 16:22 |
| By the way, doing a sock.shutdown(socket.SHUT_RDWR) with a subsequent sock.close() helps to really close an SSL socket. But this may raise additional errors with subsequent close() since on some OS (like OS X) shutdown may close the socket. Am I right? |
|
|
| msg118712 - (view) |
Author: Tiago Teresa Teodosio (TTT) |
Date: 2010-10-14 19:26 |
| I can make the connection really get closed by running the garbage collector. It seems that the SSL socket has some kind of lazy close. import gc gc.collect() |
|
|
| msg118763 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-10-15 12:43 |
| If I'm reading this thread correctly, this bug should be closed and a new one opened about SSL socket close. Antoine, does that sound correct? |
|
|
| msg118765 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-10-15 13:03 |
| Probably, yes. |
|
|
| msg118897 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-10-16 21:16 |
| I opened issue 10127 for the ssl.SSLSocket().close() problem. |
|
|