httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Date Tue, 17 Sep 2013 14:31:25 GMT
Would it also make sense to put that info into r->notes ?

On Sep 17, 2013, at 9:23 AM, Jeff Trawick <trawick@gmail.com> wrote:

> On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph <mike.rumph@oracle.com> 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/


Mime
View raw message