I try to use ftplib for a Webspace running on a Windows Server machine.
The server responses 250 instead of 257 (which would be correct according to RFC959, ftp)

It would be nice if ftplib could also tolerate the 250 "Requested file ation okay, completed" code, since I cannot change the server (or beat that M$ programmer).

Thanks!

Since this is a feature request, it could only be added to 3.2, not the other versions.

> The server responses 250 instead of 257 (which would be correct according to RFC959, ftp)

In response to what command? MKD?
And what do you mean by "tolerate"?

Yes.
If you send a "MKD" than Windows Server responses "250", and ftplib generates an Error.

Where exactly RFC-959 states that 250 is a valid response code for MKD?
Chapter 5.4 reports the following response codes:

MKD
  257
  500, 501, 502, 421, 530, 550

250 is an invalid response to MKD.
M$ Windows Server 2003 does it anyways.
M$ Windows Server is a rather common OS, and there are people like me how have to live with this.

Maybe it should put this into the following words:
"Please make ftplib usuable with M$ Win Server 2003"

What IIS version are we talking about?
Could you please paste the complete response string other than just the code?
I'm asking this because 257 response is supposed to include the name of the created directory.

Personally I don't like to include workarounds for stupid implementations like this.
If IIS erroneously replies with 250 then maybe it doesn't even include the directory name in which case FTP.mkd method is completely useless for you and you can just work around the exception by using FTP.sendcmd('MKD dirname') instead.

Well, given that both replies (expected and actual) are in the 25x category, and that (according to the RFC) “the third digit gives a finer gradation of meaning in each of the function categories, specified by the second digit”, perhaps practicality beats purity and the exact return code isn't that important as long as it falls in the right category.

(what would a Web browser do in that case? say it receives a 201 instead of a 200 or something)

Apparently bzr users hit this bug:
https://bugs.launchpad.net/bzr/+bug/224373

Jep I also discovered it by using Bazaar, but apparently it goes down to the ftplib. The bazaar fix works, and here is the response of strato.com (I use bash ftp):

ftp> open ftp.strato.com
Connected to ftp.strato.com.
220 Speak friend, and enter
Name (ftp.strato.com:ich): me@mywebsite.com
331 FTP login okay, send password.
Password:
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> mkdir test
250 Directory created.

Given Antoine comment and the link referencing bzr issue I agree we should fix this now.
A patch including tests for parse257 function is in attachment.
The exception is now raised only if the response code doesn't fall in the 2xx category; for responses != 257 '' is returned.
I'm +1 on including this only in 3.2.

This is now fixed in r84288.