Fixing ProxyPassReverse & friends

[Nick Kew <ni...@webthing.com>]

This has been discussed before(*), but I never got around
to patching it in SVN.

(1) ProxyPassReverse is documented as working inside <Location>
(2) ... but ProxyPassReverse is implemented on the *server* config.
So, although it is syntactically correct within <Location> due to a 
hack, it doesn't actually work there beyond the trivial case.
It loses the merge_dir_config, and instead collects all <Location>s
in a single array without any means of distinguishing them.

I attach two patches: one for trunk, the other for 2.0.
The 2.0 patch is in production at my Client, and combines a patch
I made for them in January (i.e. well-tested:-) with the
long-standing patch for Bug 10722 at issues.apache.org.

If noone objects I'll commit the Trunk patch and propose the
2.0 patch for backport.

(*) http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=110726027118798&w=2

-- 
Nick Kew

Re: Fixing ProxyPassReverse & friends

[Nick Kew <ni...@webthing.com>]

On Wednesday 10 August 2005 07:44, Nick Kew wrote:

> If noone objects I'll commit the Trunk patch and propose the
> 2.0 patch for backport.

OK, I've just proposed the 2.0-backport in STATUS.

I would add a couple of comments to this.

Firstly, this is in production use at the Client who first drew
attention to the ProxyPassReverse-in-<Location> bug.
I fixed it for them in January, so that's had ample test time.

Secondly, I'm seeing a lot of demand for this.  It's not
really satisfactory to have to refer everyone to Bug 10722
for cookies, especially when that doesn't deal with the
<Location> bug.   End-user requests for patched binaries
are even more problematic, and would be better dealt with
by the packagers who support a platform.

Can people please take a moment to VOTE on this backport?

-- 
Nick Kew