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 jbell
Recipients ethan.furman, giampaolo.rodola, gregory.p.smith, jbell, mikecmcleod
Date 2021-11-02.03:14:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1635822857.33.0.935748472198.issue2628@roundup.psfhosted.org>
In-reply-to
Content
I should rephrase: There doesn't seem to be a practical way to verify BLOCK transmission mode against actual servers in the wild. As the Wikipedia article that Giampaolo referenced points out, BLOCK mode is a rarity that was primarily supported only by mainframe and minicomputer systems.

Any compliant server not supporting BLOCK should respond with a non-200 response. The PR sends its request to enter BLOCK mode with self.voidcmd(), which handles non-200 responses by raising error_reply.

When I originally wrote that patch in 2008, such a system was running on a DEC Alpha under OpenVMS. Within months of the first test suite appearing for ftplib, that same vendor replaced their systems. The new server had no BLOCK transmission support, but was capable of handling multiple consecutive passive mode STREAM data connections without fault.

Even at the time, I couldn't find any other freely available FTP servers supporting BLOCK. But STREAM was and continues to be the standard.

Essentially this means that any changes to the existing PR may not be work properly with actual servers.
History
Date User Action Args
2021-11-02 03:14:17jbellsetrecipients: + jbell, gregory.p.smith, giampaolo.rodola, ethan.furman, mikecmcleod
2021-11-02 03:14:17jbellsetmessageid: <1635822857.33.0.935748472198.issue2628@roundup.psfhosted.org>
2021-11-02 03:14:17jbelllinkissue2628 messages
2021-11-02 03:14:17jbellcreate