httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: Broken URI-unescaping in mod_proxy
Date Thu, 11 Oct 2007 11:40:33 GMT
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
--



Mime
View raw message