httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Date Tue, 17 Sep 2013 15:32:53 GMT
On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:

> IMHO yes. But I am a mod_rewrite fan anyway :-).
>

not really a rewrite fan, but I think that's better than code

so IMO we should doc that interpolation isn't supported in the scheme, and
instead a solution like that should be used



>
> Regards
>
> Rüdiger
>
> > -----Original Message-----
> > From: Jim Jagielski [mailto:jim@jaguNET.com]
> > Sent: Dienstag, 17. September 2013 17:26
> > To: dev@httpd.apache.org
> > 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"
> > <ruediger.pluem@vodafone.com> 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:trawick@gmail.com]
> > > 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 <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/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message