This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author giampaolo.rodola
Recipients ethan.furman, giampaolo.rodola, gregory.p.smith, jbell, mikecmcleod
Date 2021-10-31.13:32:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1635687138.41.0.975633524904.issue2628@roundup.psfhosted.org>
In-reply-to
Content
Hello.
I added some initial comments to the PR, but I'm sort of skeptical about this. It must be noted that:

1) very few FTP servers probably support this feature (https://en.wikipedia.org/wiki/File_Transfer_Protocol#Data_transfer_modes)

2) the specs are very old (RFC-959 is from 1985), and I doubt they've been upgraded in later RFCs. The fact that a header is sent *before every data block* seems inefficient (why not just send the  file size once?), probably more inefficient that opening a new connection each time (unless files are small, I suppose).

Was this tested against an actual FTP server(s)? If yes, which one(s)? IMO, it would be good if some actual research/testing is done first, to see how actual FTP server products implement this feature.

Another thing to note is that the PR supports RETR (download) only, and not STOR (upload). Is this on purpose or does the original RFC/spec limits this functionality to RETR?
History
Date User Action Args
2021-10-31 13:32:18giampaolo.rodolasetrecipients: + giampaolo.rodola, gregory.p.smith, jbell, ethan.furman, mikecmcleod
2021-10-31 13:32:18giampaolo.rodolasetmessageid: <1635687138.41.0.975633524904.issue2628@roundup.psfhosted.org>
2021-10-31 13:32:18giampaolo.rodolalinkissue2628 messages
2021-10-31 13:32:18giampaolo.rodolacreate