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 janssen
Recipients giampaolo.rodola, gregory.p.smith, iElectric, janssen, roberte
Date 2008-03-19.20:19:51
SpamBayes Score 0.0
Marked as misclassified No
Message-id <4b3e516a0803191319i248ace4fm1773c3590ac6fb89@mail.gmail.com>
In-reply-to <1205954566.96.0.305895318869.issue2054@psf.upfronthosting.co.za>
Content
As you point out, the other classes should be fixed.  The old client-side
protocol was never very well thought out, IMHO.  Continuing to propagate it
would be a mistake.
Bill

On Wed, Mar 19, 2008 at 12:22 PM, Giampaolo Rodola' <report@bugs.python.org>
wrote:

>
> Giampaolo Rodola' <billiejoex@users.sourceforge.net> added the comment:
> > Another thing to look at is what the useful arguments are to pass in
> > for TLS usage over FTP.  If, for example, the client needs to validate
> > the server's certificate or identity, provision should be made for a
> > file of cacerts to be passed to the FTP_TLS instance.  Passing in a
> > keyfile and certfile is usually only necessary when the client uses
> > them to identify itself to the server.
>
> I drew from the SSL classes defined in httplib, imaplib, poplib, smtplib
> and urllib modules which accept a keyfile and a certfile in the class
> constructor so I thought it was the "right way". Is there a reason why
> the FTP protocol should behave differently as you have described?
>
Files
File name Uploaded
unnamed janssen, 2008-03-19.20:19:49
History
Date User Action Args
2008-07-26 13:55:06georg.brandlsetspambayes_score: 0.742661 -> 0.0
2008-03-19 20:19:53janssensetspambayes_score: 0.742661 -> 0.742661
recipients: + janssen, gregory.p.smith, giampaolo.rodola, roberte, iElectric
2008-03-19 20:19:51janssenlinkissue2054 messages
2008-03-19 20:19:51janssencreate