Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 11 Oct 2007 16:23:53 +0530
From: rahul <Rahul.G.Nair@Sun.COM>
Subject: Re: Broken URI-unescaping in mod_proxy
In-reply-to: <36735.84.233.182.145.1192028034.squirrel@www.sharp.fm>
Sender: Rahul.G.Nair@Sun.COM
To: dev@httpd.apache.org
Message-id: <20071011105353.GV99478@vayavyam.India.Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <C3313BC6.98FC3%Brian.Akins@turner.com>
 <470BFDEE.8030103@sharp.fm>
 <20071009232637.3dc60d6a@grimnir>
 <20071010132700.GL99478@vayavyam.India.Sun.COM>
 <36735.84.233.182.145.1192028034.squirrel@www.sharp.fm>
User-Agent: Mutt/1.5.11

[Graham Leggett:]
| > It would be nice to have different modules for reverse proxy and forward
| > proxy.. from an FTP perspective.
| >
| > There is a fairly large difference in FTP (and perhaps in other protocols
| > too) in terms of the optimizations that needs to be done for forward proxy
| > and reverse proxy.
| >
| > In forward proxy, we can not assume the kind of ftp servers the client
| > requests. So when there is an error of some sort we should try again
| > with a syntax that might be acceptable to the next possible type of
| > server.
| >
| > In the reverse proxy, this is wrong, and introduces unnecessary
| > overheads in network traffic (where it would be simpler to ask the user
| > to provide the type of server in the backend and error out if the ftp
| > server returns error.)
|
| There is no need to have separate module to achieve this - providing a
| mechanism to override certain behaviour when the administrator wants it,
| but defaulting to RFC compliant behaviour will achieve the same thing.

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.

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.

                                    rahul
--
1. e4 _