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/
