IMHO yes. But I am a mod_rewrite fan anyway :-). Regards
Rüdiger > -----Original Message----- > From: Jim Jagielski [mailto:[email protected]] > Sent: Dienstag, 17. September 2013 17:26 > To: [email protected] > Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by > regression to APR-util 1.5.2 > > Doesn't that completely avoid/ignore the issue in the 1st place? > > On Sep 17, 2013, at 11:08 AM, "Plüm, Rüdiger, Vodafone Group" > <[email protected]> wrote: > > > How about > > > > RewriteEngine On > > > > RewriteCond %{HTTPS} =off > > RewriteRule . - [E=protocol:http] > > RewriteCond %{HTTPS} =on > > RewriteRule . - [E=protocol:https] > > > > RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P] > > ProxyPassReverse /my_app/ http://1.2.3.4/my_app/ > > ProxyPassReverse /my_app/ https://1.2.3.4/my_app/ > > > > ? > > > > Regards > > > > Rüdiger > > > > From: Jeff Trawick [mailto:[email protected]] > > Sent: Dienstag, 17. September 2013 15:24 > > To: Apache HTTP Server Development List > > Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by > regression to APR-util 1.5.2 > > > > On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph <[email protected]> > wrote: > > Hello Jeff, > > > > Thanks for your reply. > > > > > > On 9/3/2013 6:58 AM, Jeff Trawick wrote: > > > > Since the URL validation in apr_uri_parse() has been tightened in the > handling of the scheme portion of a URL, > > I submitted a patch to httpd bug 55315 against the mod_proxy code in > httpd trunk to handle the special case > > of interpolating a variable in the scheme portion of a URL. > > > > - https://issues.apache.org/bugzilla/show_bug.cgi?id=55315 > > > > > > Do you know if it is practical to have the one magic path down to > ap_proxy_define_worker() munge the URI? I guess the problem is that > ap_proxy_define_worker() saves the parsed uri, and the caller (add_pass > or whatever it is) doesn't have access to that? > > > > I take your point to be that the mod_proxy patch I submitted cannot be > applied to the branches, since it changes the API. > > So I've submitted a new patch that is applied further up the stack in > add_pass() in mod_proxy.c. > > > > That patch > (https://issues.apache.org/bugzilla/attachment.cgi?id=30799) is the one > I'm considering, as it is the one that could solve the issue for 2.2.x > (with a minor tweak) and 2.4.x (as-is), and I don't think the function > API issue is the major concern. Instead, carrying the interpolation > expression around in the worker scheme field separate from an > interpolation flag seems to be the overriding issue. > > > > Dynamic determination of the scheme seems very useful and I don't know > of another way to implement the same requirement, which is well > illustrated by the now-broken config in the bug: > > > > ProxyPassInterpolateEnv On > > RewriteEngine On > > > > RewriteCond %{HTTPS} =off > > RewriteRule . - [E=protocol:http] > > RewriteCond %{HTTPS} =on > > RewriteRule . - [E=protocol:https] > > > > ProxyPass /my_app/ ${protocol}://1.2.3.4/my_app/ interpolate > > ProxyPassReverse /my_app/ ${protocol}://1.2.3.4/my_app/ > interpolate > > > > Any alternate ideas for configuring something like that? > > > > Otherwise, any objections to patch 30799 (URL above)? > > > > > > > > > > It is interesting that my research seems to indicate that mod_proxy > interpolation was actually the first to be introduced into the code. > > > > I guess the order is this: > > > > 1. support for environment variables in the config > > 2. mod_proxy interpolation > > 3. core server starts complaining if you have something that looks > like an envvar reference that isn't resolved > > > > Is that what you mean? > > > > The double use of ${} is nasty. In the fullness of time, I think that > mod_proxy interpolation should support an additional syntax that doesn't > collide with the config-time processing. > > > > Yes, that is the point that I was trying to make. > > > > Thanks, > > > > Mike Rumph > > > > > > > > -- > > Born in Roswell... married an alien... > > http://emptyhammock.com/
