Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jeff Trawick]

On Wed, Aug 28, 2013 at 1:11 PM, Mike Rumph  wrote:

> Hello all,
>
> 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?


There still remains a fundamental conflict between httpd configuration
> interpolation and mod_proxy interpolation.
>
> Take the example of the directives listed in bug 55315.
>
>
>  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
>
> With my mod_proxy patch applied, httpd will now start.
> But the following warnings are received:
>
> [Wed Aug 28 08:58:55.082581 2013] [core:warn] [pid 12201:tid
> 47961371215184] AH00111: Config variable ${protocol} is not defined
> [Wed Aug 28 08:58:55.083249 2013] [core:warn] [pid 12201:tid
> 47961371215184] AH00111: Config variable ${protocol} is not defined
>
> These warnings are issued by ap_resolve_env() in server/core.c.
> The syntax "${...}" is used by both httpd configuration interpolation and
> mod_proxy interpolation.
> So this syntax has to get past the httpd configuration interpolation
> before it can be processed by mod_proxy interpolation.
>
> 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.



>
> Here are some of my findings:
>
> - Trace the history of the mod_proxy interpolation code.
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=421686
> - Support environment variable interpolation in reverse proxy
> configuration
> - Committed by Nick Kew in Apache httpd 2.3.0, 7/13/2006
> - ProxyPassInterpolateEnv directive
> - http://mail-archives.apache.**org/mod_mbox/httpd-dev/200607.**
> mbox/browser
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=589371
> - Committed by Nick Kew, 10/28/2007
> - interpolate keyword
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=1065748
> - Committed by Jim, 1/31/2011
> - Added parm to ap_proxy_define_worker() and
> ap_proxy_define_balancer().
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=1207926
> - Committed by Jim, 11/29/2011
> - Added parm to ap_proxy_get_balancer().
> - Trace the history of ap_resolve_env() in server/core.c.
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=1061444
> - Committed by Stefan Fritsch, 1/20/2011.
> - Moves ap_resolve_env() from server/util.c to server/core.c.
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=1061465
> - Committed by Stefan Fritsch, 1/20/2011.
> - Changes variable translation table usage.
> - 
> http://svn.apache.org/viewvc?**view=revision&revision=546651
> - Committed by Paul Querna, 6/12/2007.
> - Add the 'Define' command to the core.
> - This does exactly the same thing as adding a -D FOO to your
> command line.
>
> Thanks,
>
> Mike Rumph
>
>
> On 8/14/2013 7:40 AM, Mike Rumph wrote:
>
>> Thanks for your reply Stefan.
>>
>> First of all, your suggestion of passing __proxy_interpolate_start__ to
>> apr_uri_parse will also fail,
>> since '_' is not accepted by the code in the "find the scheme" section as
>> a valid charact

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

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.


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

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jim Jagielski]

On Sep 3, 2013, at 9:58 AM, Jeff Trawick  wrote:

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

Agreed... as we expand mod_proxy capability (as shown via uds)
this becomes more an issue.

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jeff Trawick]

On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph  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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jim Jagielski]

Would it also make sense to put that info into r->notes ?

On Sep 17, 2013, at 9:23 AM, Jeff Trawick  wrote:

> On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph  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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jim Jagielski]

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" 
 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:traw...@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  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/

RE: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Plüm , Rüdiger , Vodafone Group]

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

Regards

Rüdiger

> -Original Message-
> From: Jim Jagielski [mailto:j...@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"
>  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:traw...@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 
> 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/

RE: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Plüm , Rüdiger , Vodafone Group]

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/<http://1.2.3.4/my_app/>$1 [P]
 ProxyPassReverse /my_app/ http://1.2.3.4/my_app/<http://1.2.3.4/my_app/>
 ProxyPassReverse /my_app/ https://1.2.3.4/my_app/<http://1.2.3.4/my_app/>

?

Regards

Rüdiger

From: Jeff Trawick [mailto:traw...@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 
mailto:mike.ru...@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/<http://1.2.3.4/my_app/> 
interpolate
 ProxyPassReverse /my_app/ 
${protocol}://1.2.3.4/my_app/<http://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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jeff Trawick]

On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@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:j...@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"
> >  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:traw...@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 
> > 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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jim Jagielski]

+1

On Sep 17, 2013, at 11:32 AM, Jeff Trawick  wrote:

> On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group 
>  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:j...@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"
> >  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:traw...@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 
> > 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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

I tried the configuration below with httpd trunk:

 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/

Then browsing to http://1.2.3.4/my_app/ gives me the following result:

*Not Found*

The requested URL /://1.2.3.4/my_app/ was not found on this server.

Any other suggestions?

Thanks,

Mike

On 9/17/2013 9:32 AM, Jim Jagielski wrote:

+1

On Sep 17, 2013, at 11:32 AM, Jeff Trawick  wrote:


On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group 
 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:j...@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"
 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:traw...@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 

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/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

Sorry.

I got carried away with the generic translation.

I was instead browsing to http://localhost:8080/my_app/

With the results indicated below.

Thanks,

Mike Rumph


On 10/8/2013 1:09 PM, Mike Rumph wrote:

I tried the configuration below with httpd trunk:

  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/
Then browsing to http://1.2.3.4/my_app/ gives me the following result:

*Not Found*

The requested URL /://1.2.3.4/my_app/ was not found on this server.

Any other suggestions?

Thanks,

Mike

On 9/17/2013 9:32 AM, Jim Jagielski wrote:

+1

On Sep 17, 2013, at 11:32 AM, Jeff Trawick  wrote:


On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone 
Group  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:j...@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"
  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:traw...@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

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

RE: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Plüm , Rüdiger , Vodafone Group]

My bad.

Needs to be

RewriteRule ^/my_app/(.*) %{ENV:protocol}://1.2.3.4/my_app/$1 [P]

Regards

Rüdiger

From: Mike Rumph
Sent: Dienstag, 8. Oktober 2013 22:17
To: dev@httpd.apache.org
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by regression to 
APR-util 1.5.2

Sorry.

I got carried away with the generic translation.

I was instead browsing to http://localhost:8080/my_app/

With the results indicated below.

Thanks,

Mike Rumph

On 10/8/2013 1:09 PM, Mike Rumph wrote:
I tried the configuration below with httpd trunk:



 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/
Then browsing to http://1.2.3.4/my_app/ gives me the following result:

Not Found

The requested URL /://1.2.3.4/my_app/ was not found on this server.

Any other suggestions?

Thanks,

Mike
On 9/17/2013 9:32 AM, Jim Jagielski wrote:

+1



On Sep 17, 2013, at 11:32 AM, Jeff Trawick 
<mailto:traw...@gmail.com> wrote:



On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group 
<mailto:ruediger.pl...@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:j...@jagunet.com]

Sent: Dienstag, 17. September 2013 17:26

To: dev@httpd.apache.org<mailto: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"

<mailto:ruediger.pl...@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:traw...@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 
<mailto:mike.ru...@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. supp

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

Okay, I've confirmed that the following configuration works for httpd 
trunk and httpd 2.2.25:


 RewriteEngine On

 


 RewriteCond %{HTTPS} =off

 RewriteRule . - [E=protocol:http]

 RewriteCond %{HTTPS} =on

 RewriteRule . - [E=protocol:https]

 


 RewriteRule ^/my_app/(.*) %{ENV: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/

So I submit the attached patch to the doc for review.

Thanks,

Mike Rumph

On 9/17/2013 9:32 AM, Jim Jagielski wrote:

   +1

   On Sep 17, 2013, at 11:32 AM, Jeff Trawick 
    wrote:

   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


Index: docs/manual/mod/mod_proxy.xml
===
--- docs/manual/mod/mod_proxy.xml   (revision 1530700)
+++ docs/manual/mod/mod_proxy.xml   (working copy)
@@ -1239,7 +1239,8 @@
 ${VARNAME}.  Note that many of the standard CGI-derived
 environment variables will not exist when this interpolation happens,
 so you may still have to resort to mod_rewrite
-for complex rules.
+for complex rules.  Also note that the syntax
+${VARNAME} is not permitted within the scheme portion of a 
URL.
 
 Normally, mod_proxy will include the query string when
 generating the SCRIPT_FILENAME environment variable.
@@ -1393,8 +1394,25 @@
 httpd 2.2.9 and later), used together with
 ProxyPassInterpolateEnv, enables interpolation
 of environment variables specified using the format ${VARNAME}.
+   Note that the syntax
+${VARNAME} is not permitted within the scheme portion of a URL. 
+   Dynamic determination of the scheme can be accomplished with 
mod_rewrite
+   as in the following example.
 
 
+
+RewriteEngine On
+
+RewriteCond %{HTTPS} =off
+RewriteRule . - [E=protocol:http]
+RewriteCond %{HTTPS} =on
+RewriteRule . - [E=protocol:https]
+
+RewriteRule ^/mirror/foo/(.*) %{ENV:protocol}://backend.example.com/$1 [P]
+ProxyPassReverse  /mirror/foo/ http://backend.example.com/
+ProxyPassReverse  /mirror/foo/ https://backend.example.com/
+
+
 When used inside a Location section, the first argument is omitted and the local
 directory is obtained from the 

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jeff Trawick]

On Wed, Oct 9, 2013 at 2:17 PM, Mike Rumph  wrote:

>  Okay, I've confirmed that the following configuration works for httpd
> trunk and httpd 2.2.25:
>
>
>  RewriteEngine On
>
> ** **
>
>  RewriteCond %{HTTPS} =off
>
>  RewriteRule . - [E=protocol:http]
>
>  RewriteCond %{HTTPS} =on
>
>  RewriteRule . - [E=protocol:https]
>
> ** **
>
>  RewriteRule ^/my_app/(.*) %{ENV: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/
>
> So I submit the attached patch to the doc for review.
>
> Thanks,
>
> Mike Rumph
>
> The patch looks reasonable to me, though I will change "is not permitted
within the scheme" to "is not supported within the scheme" since there is
no logic to disallow it (it simply doesn't work). Any concerns before I
commit?


> On 9/17/2013 9:32 AM, Jim Jagielski wrote:
>
>   +1
>
> On Sep 17, 2013, at 11:32 AM, Jeff Trawick 
> wrote:
> 
>
> 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
>
>
>


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

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Jeff Trawick]

On Wed, Oct 16, 2013 at 8:49 AM, Jeff Trawick  wrote:

> On Wed, Oct 9, 2013 at 2:17 PM, Mike Rumph  wrote:
>
>>  Okay, I've confirmed that the following configuration works for httpd
>> trunk and httpd 2.2.25:
>>
>>
>>  RewriteEngine On
>>
>> ** **
>>
>>  RewriteCond %{HTTPS} =off
>>
>>  RewriteRule . - [E=protocol:http]
>>
>>  RewriteCond %{HTTPS} =on
>>
>>  RewriteRule . - [E=protocol:https]
>>
>> ** **
>>
>>  RewriteRule ^/my_app/(.*) %{ENV: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/
>>
>> So I submit the attached patch to the doc for review.
>>
>> Thanks,
>>
>> Mike Rumph
>>
>> The patch looks reasonable to me, though I will change "is not permitted
> within the scheme" to "is not supported within the scheme" since there is
> no logic to disallow it (it simply doesn't work). Any concerns before I
> commit?
>

BTW, I moved the example to ProxyPass since that seemed to be the natural
place, and to the end of the doc for the directive so that unrelated text
didn't get trapped after the example.  This is now in trunk/2.4.x/2.2.x...

Thanks for the patch!


>
>
>> On 9/17/2013 9:32 AM, Jim Jagielski wrote:
>>
>>   +1
>>
>> On Sep 17, 2013, at 11:32 AM, Jeff Trawick 
>> wrote:
>> 
>>
>> 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
>>
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



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