[issue16298] httplib.HTTPResponse.read could potentially leave the socket opened forever
Eran Rundstein added the comment: Hm, it's been a while and I'm no longer sure :( You're right - since there is no length the user will have to call read() until he gets back ''. It's possible I forgot that assumption when speculating about this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16298] httplib.HTTPResponse.read could potentially leave the socket opened forever
Eran Rundstein added the comment: My pleasure. I had no idea about the Mercurial patch, this is the first time I have submitted a Python bug report :) I'll have a look. Thanks for merging the fix! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16298] httplib.HTTPResponse.read could potentially leave the socket opened forever
Eran Rundstein added the comment: Hello I have attached a patch that includes a (slightly broken) fix and a test case. Note that there is currently an unresolved issue: If the user reads the exact amount of bytes the server sent, read() on the socket will never have a chance to return '' and inform the user about the connection termination. This will also happen if the user reads more data than the server is sending. In that case, again, read() will not get called again so we will never know the socket is gone. One possible way to address this is perform the actual read() calls in a loop, attempting to read the exact amount the user specified. If we do this and the user attempts to read more bytes than the server sent, we will properly detect it. If, however, the user reads the exact length, then we still have a problem. I am not sure what would be the correct way of solving this. -- keywords: +patch Added file: http://bugs.python.org/file27913/httplib-no-content-length-close-sock-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16298] httplib.HTTPResponse.read could potentially leave the socket opened forever
Eran Rundstein added the comment: The patch is probably trivial - however I would still like some verification. Would it be correct to call self.close() when fp.read returns ''? In case self.length is not present, I don't see a way around this anyway. When it is present, and fp.read returns '', how should we go about that? We can either return less data, or raise an exception to indicate that the connection terminated prematurely. Thanks -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16298] httplib.HTTPResponse.read could potentially leave the socket opened forever
New submission from Eran Rundstein: When calling HTTPResponse.read() on a response that is: a. not chunked b. contains no content-length header the underlying socket (referenced by self.fp) will never get closed (through self.close()) The offending code is at the bottom of the read() function: s = self.fp.read(amt) if self.length is not None: self.length -= len(s) if not self.length: self.close() return s As seen, if self.length is None, even when the server closes the connection (causing self.fp.read to return ''), the socket will not get closed. btw, this may be the cause of Issue15633 (http://bugs.python.org/issue15633) -- components: Library (Lib) messages: 173505 nosy: eranrund priority: normal severity: normal status: open title: httplib.HTTPResponse.read could potentially leave the socket opened forever type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
