On Thu, October 11, 2007 12:53 pm, rahul wrote: > True, my point is that these choices are distributed all over the code. > While it can certainly be run together, it would be much cleaner to have > different modules with emphasis on different things while using a common > ftp_util base for things that are similar.
The ftp stuff should only be contained in mod_proxy_ftp, which is itself a submodule of mod_proxy, these changes should definitely not be all over the code. If you split mod_proxy_ftp into two, you now have two almost identical modules where one half contains a feature and the other half doesn't, leading to situations where something is supported in the reverse proxy case, but not the forward proxy case. I don't see any value in this. > Another problem is with the default behavior. What is nice for a forward > ftp proxy is not a correct default for a reverse ftp proxy (as explained > above). > > Thirdly, the FTP rfc is silent (AFAIK - please correct me if I am wrong.) > in things like LIST format. so there is no RFC compliant behavior to > default to for this. The ftp proxy handles this by following "safe" behaviour, such as "cd"ing individually to each directory component instead of assuming a potentially incorrect path separator. This makes the proxy work everywhere, but in cases where an admin knows what kind of proxy is being used, it's quite sensible to offer the admin the option to hard code a separator, or hard code a list format, so as to cut down on network traffic. None of this justifies a split in modules though. Please don't forget that mod_proxy already contains a non trivial structure: mod_proxy is a "parent" module, providing hooks to mod_proxy_http and mod_proxy_ftp, which are child modules. Splitting the modules yet again adds a documentation and support burden - now people must be educated on why they must choose module A instead of almost identical module B. Regards, Graham --
