[issue7322] Socket timeout can cause file-like readline() method to lose data

[R. David Murray]

R. David Murray <rdmurray at bitdance.com> added the comment:

This patch has caused a non-trivial regression between 3.2 and 3.2.1.  The scenario in which I observed it is poplib.  I create a POP3 connection with a timeout.  At one point in its processing, poplib is reading lines until it gets a line '.\r\n', at which point the transaction is complete and it returns data to the caller.  If the pop server fails to terminate the transaction, we get a timeout on the read.  However, the POP server may still be alive, it may just have failed to close the transaction (servers have been observed in the wild that do this[*]).  Before this patch, one could catch the socket.timeout and recover from the failed transaction (loosing the transaction data, but that's OK because the transaction was incomplete...it would be better to get the partial transaction, but that's a poplib issue, not a socket issue).  One could then continue processing, sending new transactions to the POP server and getting responses.  After the patch, once the socket error is raised there is no way to continue poplib processing short of tearing down the connection and rebuilding it, and restarting the POP processing from the beginning.

Now, this is clearly an abnormal situation (a POP server randomly not completing its transactions), but it was observed in the wild, and does represent a regression.  I think that Antoine's idea of making readline functional despite timeouts was the better approach.

Also note that Antoine's change to the makefile documentation is wrong with this patch in place, since a timeout invalidates the makefile rather than just "leaving the internal buffers in an inconsistent state".

Backing out this patch would probably be better than leaving it in place, if a better fix can't be found.

[*] The regression was detected testing against a test POP server designed to exhibit defective behaviors that have been observed over the years by the maintainers of the test server.  I can't point to specific existing servers that exhibit the broken behavior, but it did happen in the past and no doubt someone will write a buggy POP server that has the same broken behavior some time in the future as well.

----------
nosy: +r.david.murray
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________