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: domain of nickgearls@gmail.com
 designates 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=XWcvqxnEXmyPk4HQ/ekqbVSCLUD//e2pjvLpheI7jXIl5MWUNPmqr/EHVFI0wWWFDHCp+3kkWAlGUo9TRHcW3R6E/x/Any46WLWeL9O3FKSzje8+sJS5xjLXCdJZqQnMGRLW45kUaWM9eXiOruwKJvtsx31vyksph2Ae8MXG8aI=
Message-ID: <47036AF5.7050006@gmail.com>
Date: Wed, 03 Oct 2007 12:12:05 +0200
From: Nick Gearls <nickgearls@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_proxy & &headers
References: <47036ABD.6000005@gmail.com> <20071003112731.7d674646@grimnir>
    <4703728C.1020909@gmail.com> <20071003120309.3ba83b9c@grimnir>
 <14102.84.233.182.145.1191411021.squirrel@www.sharp.fm>
In-Reply-To: <14102.84.233.182.145.1191411021.squirrel@www.sharp.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I agree, we have to check if it latches the back-end before changing it 
to the front-end, and vice-versa.
This way, it sounds totally safe, no ?

Graham Leggett wrote:
> On Wed, October 3, 2007 1:03 pm, Nick Kew wrote:
> 
>> It would break headers that contain a URL-like pattern that isn't
>> a URL.  And if you think that's unlikely, just look at the number
>> of false positives in desktop software (e.g. mailers) that guesses
>> links and makes http://www.example.org or even just www.example.com
>> clickable.
> 
> As I recall the ProxyPassReverse does an exact string prefix match on
> Location, and if there is a match, the header is changed, otherwise it
> leaves the header alone.
> 
> By saying "ProxyPassReverse" it seems sane to be telling the proxy that it
> should hide every and all occurences of the backend url by replacing it
> with the frontend url, although from the perspective of changing existing
> behaviour in existing installations, a compromise would be to identify
> headers used by WebDAV, and alter those headers as well as Location.
> 
> Regards,
> Graham
> --
> 
> 
>