You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mike Rumph <mi...@oracle.com> on 2013/08/13 22:34:49 UTC
mod_proxy interpolation code broken by regression to APR-util 1.5.2
Hello all,
I had some time during the last few days to do root cause analysis on
httpd bug 55315.
- "error in ProxyPass URL parsing with interpolation"
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55315
This bug was described as a regression in Apache httpd 2.2.25.
But it is actually a regression in APR-util 1.5.2 as a result of the fix
for APR-util bug 52479.
- apr_uri_parse("@localhost::8080") reports "@localhost" for the scheme
- https://issues.apache.org/bugzilla/show_bug.cgi?id=52479
I submitted a quick fix patch against bug 55315.
But it is probably not the ultimate fix.
The bug report lists the following set of directives:
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
These directives successfully allow proxies over to the target server in httpd 2.2.22.
But they result in the following error on httpd 2.2.25:
- $ bin/httpd -X
Syntax error on line 202 of /home/mrumph/apache225/conf/httpd.conf:
ProxyPass Unable to parse URL
The ProxyPass directive is processed by the add_pass_noregex function in mod_proxy.c.
This calls add_pass which calls ap_proxy_add_worker in proxy_util.c.
ap_proxy_add_worker passes an uninterpolated URL to apr_uri_parse() in apr-util/uri/apr_uri.c.
This is true for both httpd 2.2.22 and httpd 2.2.25.
As a result of the fix for bug 52479,
apr_uri_parse no longer allows the interpolation characters (${}) to pass through cleanly.
The patch I submitted will allow the characters to pass through.
But perhaps it is not correct for mod_proxy to be passing uninterpolated URLs to apr_uri to begin with.
Perhaps the mod_proxy interpolation code should be structured differently.
mod_proxy.c does have a proxy_interpolate function,
but this is only called later through the fixups and translate_name hooks.
Any suggestions?
Thanks,
Mike Rumph
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Oct 16, 2013 at 8:49 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Wed, Oct 9, 2013 at 2:17 PM, Mike Rumph <mi...@oracle.com> 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 <tr...@gmail.com>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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Oct 9, 2013 at 2:17 PM, Mike Rumph <mi...@oracle.com> 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 <tr...@gmail.com>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
Posted by Mike Rumph <mi...@oracle.com>.
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 <tr...@gmail.com>
<ma...@gmail.com> 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
RE: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
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 <tr...@gmail.com> wrote:
On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group <ru...@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<ma...@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"
<ru...@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 <mi...@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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Mike Rumph <mi...@oracle.com>.
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<tr...@gmail.com> wrote:
>>
>>> On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group<ru...@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"
>>>> <ru...@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<mi...@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/
>
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Mike Rumph <mi...@oracle.com>.
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 <tr...@gmail.com> wrote:
>
>> On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group <ru...@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"
>>> <ru...@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 <mi...@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/
>
Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
On Sep 17, 2013, at 11:32 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group <ru...@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"
> > <ru...@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 <mi...@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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Jeff Trawick <tr...@gmail.com>.
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"
> > <ru...@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 <mi...@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/
RE: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
IMHO yes. But I am a mod_rewrite fan anyway :-).
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"
> <ru...@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 <mi...@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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
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" <ru...@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 <mi...@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/
RE: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
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: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 <mi...@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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Would it also make sense to put that info into r->notes ?
On Sep 17, 2013, at 9:23 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph <mi...@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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph <mi...@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/
Re: [PATCH 55315] mod_proxy interpolation code broken by regression
to APR-util 1.5.2
Posted by Mike Rumph <mi...@oracle.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 3, 2013, at 9:58 AM, Jeff Trawick <tr...@gmail.com> 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
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Aug 28, 2013 at 1:11 PM, Mike Rumph <mi...@oracle.com> 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<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<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://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/browser>
> - http://svn.apache.org/viewvc?**view=revision&revision=589371<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<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<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<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<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<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 character within the scheme.
>> Plus, the only first character that will be accepted is one that is
>> marked as T_ALPHA.
>>
>> Secondly, is it really a bug for apr_uri_parse() to be flexible enough to
>> allow variables within the URL to pass through?
>> This would depend on the exact API definition.
>> If this is not precisely documented somewhere,
>> then it is the code of apr_uri_parse() that is dictating the API.
>> If that is the case, then the fix for bug 52479 has changed the API.
>> Is this an acceptable thing to do between httpd 2.2.22 and 2.2.25 or
>> between APR-util 1.5.1 and 1.5.2?
>>
>> If apr_uri_parse() is not flexible enough,
>> then the callers of this function will need to be aware of this
>> and go out of their way to avoid problems with it.
>>
>> The suggestion of having mod_proxy replace variables in the scheme
>> portion of the URL
>> before calling apr_uri_parse() could be a possible way for this to be
>> handled in this case,
>> but it would mean that mod_proxy (or any other module that would want to
>> use variables)
>> would need to do part of the parsing itself.
>>
>> So I think it comes down to the question of whether or not
>> apr_uri_parse() was designed
>> to handle embedded variables. If it isn't, then mod_proxy has misused
>> the API.
>> It does have its own interpolation code, but this is only called later
>> through the fixups and translate_name hooks.
>> It could be that the values to the variables might not be reliably
>> available at the time apr_uri_parse is called.
>> So mod_proxy would need to do some special processing just to allow the
>> variables to continue to exist
>> until they can be interpolated later.
>>
>> Perhaps someone that knows more about the mod_proxy code could offer some
>> suggestions here.
>>
>> Here are the relevant bugs for easy reference:
>>
>> - 55315: error in ProxyPass URL parsing with interpolation
>> - https://issues.apache.org/**bugzilla/show_bug.cgi?id=55315<https://issues.apache.org/bugzilla/show_bug.cgi?id=55315>
>>
>> - 52479: apr_uri_parse("@localhost::**8080") reports "@localhost" for
>> the scheme
>> - https://issues.apache.org/**bugzilla/show_bug.cgi?id=52479<https://issues.apache.org/bugzilla/show_bug.cgi?id=52479>
>>
>> Take care,
>>
>> Mike Rumph
>>
>>
>> On 8/13/2013 2:17 PM, Stefan Fritsch wrote:
>>
>>> Am Dienstag, 13. August 2013, 13:34:49 schrieb Mike Rumph:
>>>
>>>> The ProxyPass directive is processed by the add_pass_noregex
>>>> function in mod_proxy.c. This calls add_pass which calls
>>>> ap_proxy_add_worker in proxy_util.c. ap_proxy_add_worker passes an
>>>> uninterpolated URL to apr_uri_parse() in apr-util/uri/apr_uri.c.
>>>> This is true for both httpd 2.2.22 and httpd 2.2.25.
>>>>
>>>> As a result of the fix for bug 52479,
>>>> apr_uri_parse no longer allows the interpolation characters (${}) to
>>>> pass through cleanly.
>>>>
>>>> The patch I submitted will allow the characters to pass through.
>>>>
>>>> But perhaps it is not correct for mod_proxy to be passing
>>>> uninterpolated URLs to apr_uri to begin with. Perhaps the mod_proxy
>>>> interpolation code should be structured differently.
>>>>
>>>
>>> This means httpd depends on a bug in apr_uri_parse(). I don't think we
>>> should re-introduce the bug, but fix httpd instead. If it needs to
>>> call apr_uri_parse() before interpolation, it could convert the
>>> special characters to strings that are acceptable in any URI part,
>>> call apr_uri_parse(), and then convert the strings back. Maybe replace
>>> '${' with __proxy_interpolate_start__ and '}' with
>>> __proxy_interpolate_end__? Or create a random string and check that it
>>> does not appear in the uri?
>>>
>>> It would be nicer if httpd could call apr_uri_parse() only after
>>> interpolation, but I don't know the relevant code and can't say if
>>> that's feasible.
>>>
>>>
>>>
>>>
>>
>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
[PATCH 55315] mod_proxy interpolation code broken by regression to
APR-util 1.5.2
Posted by Mike Rumph <mi...@oracle.com>.
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
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.
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 character within the scheme.
> Plus, the only first character that will be accepted is one that is
> marked as T_ALPHA.
>
> Secondly, is it really a bug for apr_uri_parse() to be flexible enough
> to allow variables within the URL to pass through?
> This would depend on the exact API definition.
> If this is not precisely documented somewhere,
> then it is the code of apr_uri_parse() that is dictating the API.
> If that is the case, then the fix for bug 52479 has changed the API.
> Is this an acceptable thing to do between httpd 2.2.22 and 2.2.25 or
> between APR-util 1.5.1 and 1.5.2?
>
> If apr_uri_parse() is not flexible enough,
> then the callers of this function will need to be aware of this
> and go out of their way to avoid problems with it.
>
> The suggestion of having mod_proxy replace variables in the scheme
> portion of the URL
> before calling apr_uri_parse() could be a possible way for this to be
> handled in this case,
> but it would mean that mod_proxy (or any other module that would want
> to use variables)
> would need to do part of the parsing itself.
>
> So I think it comes down to the question of whether or not
> apr_uri_parse() was designed
> to handle embedded variables. If it isn't, then mod_proxy has misused
> the API.
> It does have its own interpolation code, but this is only called later
> through the fixups and translate_name hooks.
> It could be that the values to the variables might not be reliably
> available at the time apr_uri_parse is called.
> So mod_proxy would need to do some special processing just to allow
> the variables to continue to exist
> until they can be interpolated later.
>
> Perhaps someone that knows more about the mod_proxy code could offer
> some suggestions here.
>
> Here are the relevant bugs for easy reference:
>
> - 55315: error in ProxyPass URL parsing with interpolation
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=55315
>
> - 52479: apr_uri_parse("@localhost::8080") reports "@localhost" for
> the scheme
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=52479
>
> Take care,
>
> Mike Rumph
>
>
> On 8/13/2013 2:17 PM, Stefan Fritsch wrote:
>> Am Dienstag, 13. August 2013, 13:34:49 schrieb Mike Rumph:
>>> The ProxyPass directive is processed by the add_pass_noregex
>>> function in mod_proxy.c. This calls add_pass which calls
>>> ap_proxy_add_worker in proxy_util.c. ap_proxy_add_worker passes an
>>> uninterpolated URL to apr_uri_parse() in apr-util/uri/apr_uri.c.
>>> This is true for both httpd 2.2.22 and httpd 2.2.25.
>>>
>>> As a result of the fix for bug 52479,
>>> apr_uri_parse no longer allows the interpolation characters (${}) to
>>> pass through cleanly.
>>>
>>> The patch I submitted will allow the characters to pass through.
>>>
>>> But perhaps it is not correct for mod_proxy to be passing
>>> uninterpolated URLs to apr_uri to begin with. Perhaps the mod_proxy
>>> interpolation code should be structured differently.
>>
>> This means httpd depends on a bug in apr_uri_parse(). I don't think we
>> should re-introduce the bug, but fix httpd instead. If it needs to
>> call apr_uri_parse() before interpolation, it could convert the
>> special characters to strings that are acceptable in any URI part,
>> call apr_uri_parse(), and then convert the strings back. Maybe replace
>> '${' with __proxy_interpolate_start__ and '}' with
>> __proxy_interpolate_end__? Or create a random string and check that it
>> does not appear in the uri?
>>
>> It would be nicer if httpd could call apr_uri_parse() only after
>> interpolation, but I don't know the relevant code and can't say if
>> that's feasible.
>>
>>
>>
>
>
>
Re: mod_proxy interpolation code broken by regression to APR-util
1.5.2
Posted by Mike Rumph <mi...@oracle.com>.
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 character within the scheme.
Plus, the only first character that will be accepted is one that is
marked as T_ALPHA.
Secondly, is it really a bug for apr_uri_parse() to be flexible enough
to allow variables within the URL to pass through?
This would depend on the exact API definition.
If this is not precisely documented somewhere,
then it is the code of apr_uri_parse() that is dictating the API.
If that is the case, then the fix for bug 52479 has changed the API.
Is this an acceptable thing to do between httpd 2.2.22 and 2.2.25 or
between APR-util 1.5.1 and 1.5.2?
If apr_uri_parse() is not flexible enough,
then the callers of this function will need to be aware of this
and go out of their way to avoid problems with it.
The suggestion of having mod_proxy replace variables in the scheme
portion of the URL
before calling apr_uri_parse() could be a possible way for this to be
handled in this case,
but it would mean that mod_proxy (or any other module that would want to
use variables)
would need to do part of the parsing itself.
So I think it comes down to the question of whether or not
apr_uri_parse() was designed
to handle embedded variables. If it isn't, then mod_proxy has misused
the API.
It does have its own interpolation code, but this is only called later
through the fixups and translate_name hooks.
It could be that the values to the variables might not be reliably
available at the time apr_uri_parse is called.
So mod_proxy would need to do some special processing just to allow the
variables to continue to exist
until they can be interpolated later.
Perhaps someone that knows more about the mod_proxy code could offer
some suggestions here.
Here are the relevant bugs for easy reference:
- 55315: error in ProxyPass URL parsing with interpolation
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55315
- 52479: apr_uri_parse("@localhost::8080") reports "@localhost" for the
scheme
- https://issues.apache.org/bugzilla/show_bug.cgi?id=52479
Take care,
Mike Rumph
On 8/13/2013 2:17 PM, Stefan Fritsch wrote:
> Am Dienstag, 13. August 2013, 13:34:49 schrieb Mike Rumph:
>> The ProxyPass directive is processed by the add_pass_noregex
>> function in mod_proxy.c. This calls add_pass which calls
>> ap_proxy_add_worker in proxy_util.c. ap_proxy_add_worker passes an
>> uninterpolated URL to apr_uri_parse() in apr-util/uri/apr_uri.c.
>> This is true for both httpd 2.2.22 and httpd 2.2.25.
>>
>> As a result of the fix for bug 52479,
>> apr_uri_parse no longer allows the interpolation characters (${}) to
>> pass through cleanly.
>>
>> The patch I submitted will allow the characters to pass through.
>>
>> But perhaps it is not correct for mod_proxy to be passing
>> uninterpolated URLs to apr_uri to begin with. Perhaps the mod_proxy
>> interpolation code should be structured differently.
>
> This means httpd depends on a bug in apr_uri_parse(). I don't think we
> should re-introduce the bug, but fix httpd instead. If it needs to
> call apr_uri_parse() before interpolation, it could convert the
> special characters to strings that are acceptable in any URI part,
> call apr_uri_parse(), and then convert the strings back. Maybe replace
> '${' with __proxy_interpolate_start__ and '}' with
> __proxy_interpolate_end__? Or create a random string and check that it
> does not appear in the uri?
>
> It would be nicer if httpd could call apr_uri_parse() only after
> interpolation, but I don't know the relevant code and can't say if
> that's feasible.
>
>
>
Re: mod_proxy interpolation code broken by regression to APR-util 1.5.2
Posted by Stefan Fritsch <sf...@sfritsch.de>.
Am Dienstag, 13. August 2013, 13:34:49 schrieb Mike Rumph:
> The ProxyPass directive is processed by the add_pass_noregex
> function in mod_proxy.c. This calls add_pass which calls
> ap_proxy_add_worker in proxy_util.c. ap_proxy_add_worker passes an
> uninterpolated URL to apr_uri_parse() in apr-util/uri/apr_uri.c.
> This is true for both httpd 2.2.22 and httpd 2.2.25.
>
> As a result of the fix for bug 52479,
> apr_uri_parse no longer allows the interpolation characters (${}) to
> pass through cleanly.
>
> The patch I submitted will allow the characters to pass through.
>
> But perhaps it is not correct for mod_proxy to be passing
> uninterpolated URLs to apr_uri to begin with. Perhaps the mod_proxy
> interpolation code should be structured differently.
This means httpd depends on a bug in apr_uri_parse(). I don't think we
should re-introduce the bug, but fix httpd instead. If it needs to
call apr_uri_parse() before interpolation, it could convert the
special characters to strings that are acceptable in any URI part,
call apr_uri_parse(), and then convert the strings back. Maybe replace
'${' with __proxy_interpolate_start__ and '}' with
__proxy_interpolate_end__? Or create a random string and check that it
does not appear in the uri?
It would be nicer if httpd could call apr_uri_parse() only after
interpolation, but I don't know the relevant code and can't say if
that's feasible.