-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rich Cook wrote: > > On Jul 13, 2007, at 12:29 PM, Micah Cowan wrote: > >> >>> sprintf(filecopy, "\"%.2047s\"", file); >> >> This fix breaks the FTP protocol, making wget instantly stop working >> with many conforming servers, but apparently start working with yours; >> the RFCs are very clear that the file name argument starts right after >> the string "RETR "; the very next character is part of the file name, >> including if the next character is a space (or a quote). The file name >> is terminated by the CR LF sequence (which implies that the sequence CR >> LF may not occcur in the filename). Therefore, if you ask for a file >> "file.txt", a conforming server will attempt to find and deliver a file >> whose name begins and ends with double-quotes. >> >> Therefore, this seems like a server problem. > > I think you may well be correct. I am now unable to reproduce the > problem where the server does not recognize a filename unless I give it > quotes. In fact, as you say, the server ONLY recognizes filenames > WITHOUT quotes and quoting breaks it. I had to revert to the non-quoted > code to get proper behavior. I am very confused now. I apologize > profusely for wasting your time. How embarrassing!
No worries, it happens! Sometimes the tests we run go other than we think they did. :) > > I'll save this email, and if I see the behavior again, I will provide > you with the details you requested below. That would be terrific, thanks. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmpOD7M8hyUobTrERCA7FAJ4oygvX7rpQy1k5FL7j3R12LUdWUACfVHrc sk1tpS12pDYBvVbD4Nv7/I4= =KCxk -----END PGP SIGNATURE-----
