[issue25458] ftplib: command response shift - mismatch
Ivan Pozdeev
report at bugs.python.org
Tue Dec 13 12:11:25 EST 2016
Ivan Pozdeev added the comment:
One more concern about the fix (so that you don't assume I didn't think of this ;) ) - handling of errors signified by the end-of-transfer response.
Handling a response in a close handler prevents us from actually checking its code:
* destructors like a close handler cannot raise exceptions because that would disrupt the resource release process
* and they're routinely called from `finally', so an exception would mask the current one if there's any (it's impossible to check within a finally block if it was was called as a result of an exception - http://stackoverflow.com/questions/1611561/can-i-get-the-exception-from-the-finally-block-in-python).
Now,
* The errors where the transfer never starts are detected by `ntransfercmd' either when opening the socket (425) or checking the first response (55x)
* an exception when opening the socket would result in the response not being read.
* The errors when the transfer ends prematurely
* are either handled by the socket (connection reset/timeout)
* or can be detected by checking data length against the real one if it's available <- these are not currently handled
* if it results from the user closing the socket prematurely (426), it _should_ be ignored
* otherwise, we can wrap recv(), too, and check the response if the underlying fn returns ''
* If the error is local (an exception is raised in other code), the server's response doesn't matter
Looks like fixing this part warrants a separate ticket, though it does affect which option to take at this step - it speaks in favor of wrapping the data socket.
I'll ask at python-dev for some feedback before I go any way.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________
More information about the Python-bugs-list
mailing list