-----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/
