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 Jeff Dafoe
Recipients Arfrever, Jeff Dafoe, akuchling, barry, benjamin.peterson, christian.heimes, georg.brandl, giampaolo.rodola, inc0, josiahcarlson, larry, neologix, pitrou, python-dev, raduv, serhiy.storchaka, stutzbach
Date 2018-08-13.13:14:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1534166073.78.0.56676864532.issue16038@psf.upfronthosting.co.za>
In-reply-to
Content
I have a question about this old patch, as it just came down in a CentOS 6 update. I think the patch is applied to the data channel in ASCII mode and not just the control channel. On the data channel in ASCII mode, there should be no assumption of maximum line length before EOL. I saw that your current value came from vsftpd's header file. I'm guessing if you look at the implementation, it's either only applied to the control channel or it's just used to set a single read size inside of a loop.  Examples of ASCII mode files that can exceed nearly any MAXLINE value without EOL are XML files or EDI files.
History
Date User Action Args
2018-08-13 13:14:35Jeff Dafoesetrecipients: + Jeff Dafoe, barry, akuchling, georg.brandl, josiahcarlson, pitrou, larry, giampaolo.rodola, christian.heimes, benjamin.peterson, stutzbach, Arfrever, neologix, python-dev, serhiy.storchaka, raduv, inc0
2018-08-13 13:14:33Jeff Dafoesetmessageid: <1534166073.78.0.56676864532.issue16038@psf.upfronthosting.co.za>
2018-08-13 13:14:33Jeff Dafoelinkissue16038 messages
2018-08-13 13:14:33Jeff Dafoecreate