Fantastic. FTP proxy has been funky for some time now (but was working if hobbling in 1.3.23 drop). When I do connect in the BillR way that might wrap up the thing mostly.
Chuck On Friday, January 25, 2002, at 11:33 AM, Martin Kraemer wrote: > I am currently working on modifying the FTP proxy. Several things > do not work correctly: > > * the proxy goes into "TYPE I" pretty quickly. However, binary transfers > are inappropriate for directory listings, especially when you connect > to an EBCDIC machine :-O > IMO, "TYPE I" should be sent directly before trying RETR, and should > be set back to "TYPE A" again when RETR failed and we are getting a > LISTing instead. See RFC959. > Also, the suffix ";type=[aid]" could be extended to allow for > ";type=e" > for forced EBCDIC transfer ;-) Not that I know a client which uses > it. > > * The code path thru the proxy_ftp_handler is rather convoluted. My > rewrite > funnels each return() thru a common function which cleans up, closing > BUFFs or sockets where needed. The current code has MANY returns which > do not clean up properly. This led to my Apache server running out of > children after a while (because each child kept an open FTP connection > to the ftp server). "Apachectl restart" saved the day ;-) > > * the so called "%2F" hack, which would allow a user of the proxy to > selectively start with either her home dir (ftp://user@host/) or > with the root dir of the system (by using ftp://user@host/%2f/) > is implemented in squid. Wouldn't it be nice to have it in our proxy > too? > > * Speaking of %2f: Apache's verification checks for path components > are not executed for the ftp proxy, it uses its own url encoding > and decoding, and many security checks are missing there. You can > go get ftp://user@host/%2fetc%2fpasswd or even > ftp://user@host/%2fetc%2fdefaults%2f%2e%2e%2fgroup > without any complaints by the proxy. >
