tis 2012-09-04 klockan 16:29 -0600 skrev Alex Rousskov: > Why would "the second" approach be required by some? In other words, > what kind of FTP functionality the first approach cannot support? I do > not favor the second approach, but I would like to know what we are > losing by using the first approach (other than some performance).
FTP is a rather messy protocol with many commands including site specific commands which can not be easily mapped to HTTP semantics And server state is also quite complex compared to HTTP. If you do cd /some/path/symlink cd .. then you end up in .. relative to the symlink, not /some/path/, which is a bit of a headache for mapping longer sessions. On servers using drive names/letters state gets even messier as you then usually have one active path per drive. I.e. windows/dos and various old mainframe OS:es. But we do not need to cater for them all unless you plan on intercepting port 21. And even then most of the odd ones can be ignored if there is an acl to bypass interception on selected sites or users. Regards Henrik
