Message181635
| Author | giampaolo.rodola |
|---|---|
| Recipients | benjamin.peterson, christian.heimes, georg.brandl, giampaolo.rodola, inc0, neologix, pitrou |
| Date | 2013-02-07.18:00:31 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1360260031.31.0.681298631733.issue16038@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
LineTooLong should be added to ftplib.all_errors. 4096 looks enough to me. The longest lines I can think of occur when processing MLSD command which produces an output of like this: type=file;size=156;perm=r;modify=20071029155301;unique=801cd2; music.mp3 type=dir;size=0;perm=el;modify=20071127230206;unique=801e33; ebooks type=file;size=211;perm=r;modify=20071103093626;unique=801e32; module.py Considering that the file names listed in there are forced to consist of base names (as opposed to *full* path names) I doubt we'll ever hit 4096. In pyftpdlib I used 2048 bytes. I can't recall any reference about this in any FTP-related RFC. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2013-02-07 18:00:31 | giampaolo.rodola | set | recipients: + giampaolo.rodola, georg.brandl, pitrou, christian.heimes, benjamin.peterson, neologix, inc0 |
| 2013-02-07 18:00:31 | giampaolo.rodola | set | messageid: <1360260031.31.0.681298631733.issue16038@psf.upfronthosting.co.za> |
| 2013-02-07 18:00:31 | giampaolo.rodola | link | issue16038 messages |
| 2013-02-07 18:00:31 | giampaolo.rodola | create | |