Sohaib Ahmad added the comment:
I finally found the actual problem causing the failure of second download.
urlretrieve() works with FTP in PASV mode, and in PASV mode after sending the
file to client, the FTP server sends an ACK that the file has been transferred.
After the fix of issue1067702 socket was being closed without receiving this
ACK.
Now, when a user tries to download the same file or another file from same
directory, the key (host, port, dirs) remains the same so open_ftp() skips ftp
initialization. Because of this skipping, previous FTP connection is reused and
when new commands are sent to the server, server first sends the previous ACK.
This causes a domino effect and each response gets delayed by one and we get an
exception from parse227().
Expected response:
*cmd* 'RETR Contents-udeb-ppc64el.gz'
*resp* '150 Opening BINARY mode data connection for
Contents-udeb-ppc64el.gz (26555 bytes).'
*resp* '226 Transfer complete.'
*cmd* 'TYPE I'
*resp* '200 Switching to Binary mode.'
*cmd* 'PASV'
*resp* '227 Entering Passive Mode (130,239,18,173,137,59).'
Actual response:
*cmd* 'RETR Contents-udeb-ppc64el.gz'
*resp* '150 Opening BINARY mode data connection for
Contents-udeb-ppc64el.gz (26555 bytes).'
*cmd* 'TYPE I'
*resp* '226 Transfer complete.'
*cmd* 'PASV'
*resp* '200 Switching to Binary mode.'
I am attaching a new patch (urllib.patch) which fixes this problem by clearing
the FTP server responses first if an existing connection is being used to
download a file. Please review and let me know if it looks good.
----------
Added file: http://bugs.python.org/file44712/urllib.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27973>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
