Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On Mon, 28 Mar 2011 15:08:13 -0400 Jim Jagielski wrote: > Assuming > > ProxyPass /foo http://www.example.com/foo > > should ProxyPass automatically create the corresponding > ProxyPassReverse statement? The thought had crossed my mind, not least with reference to mod_proxy_html. > It seems bogus to me that we still require such things... > > Of course, we can't get rid of it completely, to handle such > cases as: > > ProxyPass / ajp://localhost:8009/jsp/ > ProxyPassReverse / http://www.example.com/jsp/ Exactly, there are complexities. > but shouldn't we automagically handle the "common" case?? It's a nice idea, that would be nicer still if it would also handle the related cookie directives. This kind-of feels like a macro on top of the existing directives. How about preserving the existing directives, but offering something new and higher level? (or ) # ProxyPass flags # any non-inferred ProxyPassReverse/etc directives # Other stuff such as authnz, filters, etc -- Nick Kew Available for work, contract or permanent. http://www.webthing.com/~nick/cv.html
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 3/28/2011 2:08 PM, Jim Jagielski wrote: > Assuming > > ProxyPass /foo http://www.example.com/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.
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
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 http://www.example.com/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??
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
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 http://www.example.com/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.
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
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 http://www.example.com/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.
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? It seems bogus to me that we still require such things... Of course, we can't get rid of it completely, to handle such cases as: ProxyPass / ajp://localhost:8009/jsp/ ProxyPassReverse / http://www.example.com/jsp/ but shouldn't we automagically handle the "common" case?? Big +1 here. -- -- Daniel Ruggeri
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 29 Mar 2011, at 12:10 AM, Jim Jagielski wrote: 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. What I did to handle the "slow list" case for both ProxyPass and CacheEnable (which was modeled on ProxyPass originally) was to teach the directive to have a once-only per-directory value, which takes precedence if set, but reverts to the slow list if unset. It may be worth doing the same with ProxyPassReverse? And if nothing matches, we can default to sensible behaviour (ie automated ProxyPassReverse). Does this make sense? Regards, Graham --
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 3/28/2011 6:03 PM, Graham Leggett wrote: > On 29 Mar 2011, at 12:10 AM, Jim Jagielski wrote: > >> 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. > > What I did to handle the "slow list" case for both ProxyPass and CacheEnable > (which was > modeled on ProxyPass originally) was to teach the directive to have a > once-only > per-directory value, which takes precedence if set, but reverts to the slow > list if unset. My suggestion isn't per-dir. It's a r->notes which is even more efficient.
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: My suggestion isn't per-dir. It's a r->notes which is even more efficient. One further thing - it would need to work sanely from within a LocationMatch too. Regards, Graham --
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 3/28/2011 6:19 PM, Graham Leggett wrote: > On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: > >> My suggestion isn't per-dir. It's a r->notes which is even more efficient. > > One further thing - it would need to work sanely from within a LocationMatch > too. Regex's aren't generally reversible (differential?). With a clever set of grouping operations, perhaps you could get back there, but I doubt it.
Re: new ProxyPass/ProxyPassReverse "feature" for 2.4??
On 3/28/2011 6:31 PM, William A. Rowe Jr. wrote: > On 3/28/2011 6:19 PM, Graham Leggett wrote: >> On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: >> >>> My suggestion isn't per-dir. It's a r->notes which is even more efficient. >> >> One further thing - it would need to work sanely from within a LocationMatch >> too. > > Regex's aren't generally reversible (differential?). With a clever set of > grouping operations, perhaps you could get back there, but I doubt it. And it's the same reason that RewriteMatch [P] operations can't be reflected back to an origin path in any sane way. Our classic ProxyPassReverse isn't going anywhere soon :) The interesting question is, once we can determine origin/target uri paths, which gets applied first? The ProxyPassReverse transformations, or the direct ProxyPass reversal?
RE: new ProxyPass/ProxyPassReverse "feature" for 2.4??
> -Original Message- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: Montag, 28. März 2011 21:08 > To: dev@httpd.apache.org > Subject: new ProxyPass/ProxyPassReverse "feature" for 2.4?? > > Assuming > > ProxyPass /foo http://www.example.com/foo > > should ProxyPass automatically create the corresponding > ProxyPassReverse statement? > > It seems bogus to me that we still require such things... > > Of course, we can't get rid of it completely, to handle such > cases as: > > ProxyPass / ajp://localhost:8009/jsp/ > ProxyPassReverse / http://www.example.com/jsp/ > > but shouldn't we automagically handle the "common" case?? If this behaviour is well documented and could be turned off I am +0. I want to avoid a "smart" server getting in the way of an admin if the situation requires special handling. Regards Rüdiger
