On Sun, 22 May 2011, Mykyta Yevstifeyev wrote:
I'm writing to ask people to comment my draft draft-yevstifeyev-ftp-uri-scheme, that may be found here:
HiI think the document looks fine and basically repeats what RFC1738 says. It would be really helpful if it would mention where or how it differs from RFC1738.
My concern is "The <ftp-path> Part", section 2.2.3, and the problems aren't really introduced by you but repeating existing problems in a brand new document seems a bit unnecessary.
The original problem I have with this exists already in RFC1738 as it mandates a CWD command for each <cwd> part of the path. There are lots of servers out in the wild who are configured to not allow this, but yet allows the client to do a single CWD to the entire path. That means "CWD dir1/dir2" works while "CWD dir1" fails. We can of course just consider such servers as non-compliant but clients may still need to consider this (and I know lots of clients only do the CWD <full path> approach).
The next problem in the same section is what to do with empty <cwd> parts. As in "ftp://example.com/path1//path2";. RFC1738 acknowledges that the <cwd> parts may be empty. It continues to say that each <cwd> should result as an argument to CWD. But lots of FTP servers will treat "CWD" with a blank argument similar to what unix machines does with 'cd' without a directory: it changes directory to a pre-determined location (home directory) that certainly is not at all what the client wants for this. A "normal" FTP client will therefore not issue a separate CWD for empty parts.
In draft-yevstifeyev-ftp-uri-scheme there's no mention of the fact that <cwd> can be empty (which isn't really solving how to deal with them) but there's a similar mention that each <cwd> should be passed on to CWD.
-- / daniel.haxx.se
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.