httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
Date Mon, 28 Mar 2011 22:10:37 GMT

On Mar 28, 2011, at 4:11 PM, William A. Rowe Jr. wrote:

> On 3/28/2011 2:53 PM, Jim Jagielski wrote:
>> On Mar 28, 2011, at 3:46 PM, William A. Rowe Jr. wrote:
>>> On 3/28/2011 2:08 PM, Jim Jagielski wrote:
>>>> Assuming
>>>> 	ProxyPass /foo
>>>> should ProxyPass automatically create the corresponding
>>>> ProxyPassReverse statement?
>>> No.  The right logic is to not use the ProxyPassReverse mapping
>>> mechanics at all, they are horribly inefficient.
>>> Note the prev / replace pair in the request during the initial
>>> ProxyPass match, and on the response side, instead of/in addition to
>>> looking in the ProxyPassReverse map, perform this one and only one
>>> remapping based on the noted replacement.
>>> Perhaps ProxyPass needs a flag to say 'no, don't reverse this',
>>> but I sort of doubt it.
>> Huh? So how do you propose taking care of handling
>> the Location redirects??
> That's why I suggest 'in addition to'.  Some things may not be
> possible.  mod_rewrite [P]'s likely need ProxyPassReverse to stick
> around a while, too. The question comes down to, is there a reason
> not to try to reverse map back the original request by the match
> within the ProxyPass lookups, if it was found?
> Where we know the origin url and target proxypass url (including
> that of the one specific balancer member), we are all set to note
> this pair and perform the reverse translation later.  No need to
> search through a huge pattern table.

I *think* we're talking the same thing here... you seem to be
focusing on how ProxyPassReverse is currently implemented, which
is horribly slow, but but making ProxyPass automatically handle
the default PPR case means we don't need to use that implementation.

View raw message