httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike venzke <>
Subject Re: mod_proxy per-directory settings handling
Date Wed, 16 Jun 2010 05:26:12 GMT
Anyway, we'll file a bug report later in the week with an example config and
proposed solution. As it is now, there's no way to properly use
ProxyPassReverse in a directory scope when you use inherited settings in
nested Locations with other modules. The Locations need to be in
least-specific to most-specific order for every other module to work right,
but doing so puts the mod_proxy aliases also in least-specific to
most-specific order, which is the opposite it expects.

I think it would somehow have to merge the server-scope aliases in forward
order and the directory-scope ones in reverse order, or just remove the
ability to put those in directory scope.

- mike

On Tue, Jun 15, 2010 at 9:50 PM, <> wrote:

> Ah, I see. Iow, when you have proxypass or proxypassreverse directives in
> server config, first match wins and per-directory merging works accordingly.
> However, as in our case, when all proxypassreverse directives are instead
> within Location tags, and it's always ProxyPassReverse / xxx, I don't see a
> way to properly match the right proxypassreverse directive if it also
> matches a less-specific location, given what I said before about the
> ordering.
> I don't think there's a way to make it work properly in per-location
> without changing the code.
> Sent via BlackBerry from SingTel!
> -----Original Message-----
> From: Eric Covener <>
> Date: Tue, 15 Jun 2010 09:07:36
> To: <>
> Reply-To:
> Subject: Re: mod_proxy per-directory settings handling
> > Am I wrong? Is there some other reason why mod_proxy needs to go through
> the
> > aliases in forward order, maybe related to regex matching?
> Just convention that the first match is the operative one (which is
> also why the "!" rules have to come before whatever would match them).
>  Could make it configurable but probably not a candidate for a change
> in default (IMO)
> --
> Eric Covener

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message