Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 46713 invoked from network); 9 Aug 2005 14:39:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Aug 2005 14:39:06 -0000 Received: (qmail 95332 invoked by uid 500); 9 Aug 2005 14:38:55 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 95212 invoked by uid 500); 9 Aug 2005 14:38:54 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 95187 invoked by uid 99); 9 Aug 2005 14:38:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Aug 2005 07:38:54 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [203.22.237.243] (HELO fester.gatesec.net) (203.22.237.243) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Aug 2005 07:39:16 -0700 From: Jon Snow Reply-To: jsnow27@gatesec.net To: dev@httpd.apache.org Subject: Re: mod_proxy_ftp BASE REF Date: Wed, 10 Aug 2005 00:38:47 +1000 User-Agent: KMail/1.5.4 References: <200508091903.39111.jsnow27@gatesec.net> <42F88762.7060108@sharp.fm> In-Reply-To: <42F88762.7060108@sharp.fm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508100038.47860.jsnow27@gatesec.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Graham, Thanks. This patch definately will do the trick as I have already applied the same to test it. The browser reuses the original user:password@URL syntax for each subsequent relative URL access. This results in the same behaviour as using a squid proxy which does not use a base href. As yourself and Nick cannot find a reason for the base href either I feel more confident to patch our production systems without breaking anything. I am unsure whether this would be considered a bug or not though without feedback from the original implementor. In my mind it doesn't seem to make sense, in normal operation, to rewrite content on a proxy overriding the client's view of the world. Any opinions on whether this would be considered a bug? Regards, Jon On Tuesday 09 August 2005 20:37, Graham Leggett wrote: > Jon Snow wrote: > > Does anyone have any idea why/whether the BASE HREF is required in the > > proxy_ftp html code returned to the client? I would like to remove it as > > it is breaking relative links for my client's browsers that are not using > > an Authorization header. I have not found anywhere in the RFCs where it > > is stipulated as a must for the BASE HREF or that browsers must use the > > authorization header for requests subsequent to the initial authorization > > using the user:password combination in the URL. e.g. ftp:// > > user:password@ftp.example.com. > > Also see no reason for the base href. Does this patch do the trick for you? > > Regards, > Graham > -- ftp.patch Index: modules/proxy/mod_proxy_ftp.c =================================================================== --- modules/proxy/mod_proxy_ftp.c (revision 231016) +++ modules/proxy/mod_proxy_ftp.c (working copy) @@ -352,11 +352,10 @@ /* print "ftp://host/" */ str = apr_psprintf(p, DOCTYPE_HTML_3_2 "\n \n %s%s%s\n" - " \n \n" + " \n" " \n

Directory of " "%s/%s", site, basedir, ap_escape_html(p, path), - site, basedir, ap_escape_uri(p, path), site, str); APR_BRIGADE_INSERT_TAIL(out, apr_bucket_pool_create(str, strlen(str),