httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rahul <Rahul.G.N...@Sun.COM>
Subject Re: Broken URI-unescaping in mod_proxy
Date Thu, 11 Oct 2007 12:41:37 GMT
[Graham Leggett:]
| > 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.

Since the discussion was about merits of splitting mod_proxy into reverse
and forward proxy modules, I assumed that the corresponding for ftp too.

| 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.

Things that are identical can be factored out (as I mentioned) into a
separate util file.

| > 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.

This is one place. (LIST/NLST) where different systems vary widely in
their implementation.

Another is how you interpret the result of SIZE command (not in RFC,
but most implement it - so if it works it is a file if it does not it
_may_ be a directory.)

A different one is what kind of connection you use to transfer data,

One more is how you do CWD as you have mentioned above.

Another is that you may want to restrict the ftp server you front end to
some users with out going to the ftp server to verify.

In the case of a forward proxy you cant expect to get any of these
information from the configuration. So you start with the most general
assumption, and if it fails, you try the next one by interrogating the
server. The requirement of highest importance is to try to find a
sequence of commands that matches the request and serve it.

For a reverse proxy, the scenario changes. You assume with a default
assumption which may (most possibly) partially be supplied by the
configuration, Thus if the ftp server returns an error on any thing, you
error out and return with out trying any thing else. The requirement
here is to avoid loading the FTP server you are front ending too much.

The conflict between these two interests can be seen in all the places I

I think a better way to do this is to code it around two state-machines,
one each for RFP and FFP. The STM should be responsible for what step to
take after each response/error from the server, If we do that then it will
be possible to localize the above decisions to just those with the rest
of FTP code being shared.

| 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.

IMHO the people generally think of their setup as either of a proxy or
as a load balancer/reverse proxy.  It would be easy for them to make the
connection. We do have a precedence in different directives having a large
overlap as in ProxyPass and Rewrite rules.

In case you do have spare time, and working on the mod_proxy_ftp, could
you please review the patches (41676, 43231, 43275, 31490, 27835)? I had
submitted these some time back but does not seem to have garnered any

1. e4 _

View raw message