httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Rumph <mike.ru...@oracle.com>
Subject Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Date Tue, 08 Oct 2013 20:16:38 GMT
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<trawick@gmail.com>  wrote:
>>
>>> On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group<ruediger.pluem@vodafone.com>
 wrote:
>>> IMHO yes. But I am a mod_rewrite fan anyway :-).
>>>
>>> not really a rewrite fan, but I think that's better than code
>>>
>>> so IMO we should doc that interpolation isn't supported in the scheme, and instead
a solution like that should be used
>>>
>>>   
>>>
>>> Regards
>>>
>>> Rüdiger
>>>
>>>> -----Original Message-----
>>>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>>>> Sent: Dienstag, 17. September 2013 17:26
>>>> To:dev@httpd.apache.org
>>>> Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
>>>> regression to APR-util 1.5.2
>>>>
>>>> Doesn't that completely avoid/ignore the issue in the 1st place?
>>>>
>>>> On Sep 17, 2013, at 11:08 AM, "Plüm, Rüdiger, Vodafone Group"
>>>> <ruediger.pluem@vodafone.com>  wrote:
>>>>
>>>>> How about
>>>>>
>>>>>       RewriteEngine On
>>>>>
>>>>>       RewriteCond %{HTTPS} =off
>>>>>       RewriteRule . - [E=protocol:http]
>>>>>       RewriteCond %{HTTPS} =on
>>>>>       RewriteRule . - [E=protocol:https]
>>>>>
>>>>>       RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
>>>>>       ProxyPassReverse /my_app/http://1.2.3.4/my_app/
>>>>>       ProxyPassReverse /my_app/https://1.2.3.4/my_app/
>>>>>
>>>>> ?
>>>>>
>>>>> Regards
>>>>>
>>>>> Rüdiger
>>>>>
>>>>> From: Jeff Trawick [mailto:trawick@gmail.com]
>>>>> Sent: Dienstag, 17. September 2013 15:24
>>>>> To: Apache HTTP Server Development List
>>>>> Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
>>>> regression to APR-util 1.5.2
>>>>> On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph<mike.rumph@oracle.com>
>>>> wrote:
>>>>> Hello Jeff,
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>>
>>>>> On 9/3/2013 6:58 AM, Jeff Trawick wrote:
>>>>>
>>>>> Since the URL validation in apr_uri_parse() has been tightened in the
>>>> handling of the scheme portion of a URL,
>>>>> I submitted a patch to httpd bug 55315 against the mod_proxy code in
>>>> httpd trunk to handle the special case
>>>>> of interpolating a variable in the scheme portion of a URL.
>>>>>
>>>>> -https://issues.apache.org/bugzilla/show_bug.cgi?id=55315
>>>>>
>>>>>
>>>>> Do you know if it is practical to have the one magic path down to
>>>> ap_proxy_define_worker() munge the URI?  I guess the problem is that
>>>> ap_proxy_define_worker() saves the parsed uri, and the caller (add_pass
>>>> or whatever it is) doesn't have access to that?
>>>>> I take your point to be that the mod_proxy patch I submitted cannot be
>>>> applied to the branches, since it changes the API.
>>>>> So I've submitted a new patch that is applied further up the stack in
>>>> add_pass() in mod_proxy.c.
>>>>> That patch
>>>> (https://issues.apache.org/bugzilla/attachment.cgi?id=30799) is the one
>>>> I'm considering, as it is the one that could solve the issue for 2.2.x
>>>> (with a minor tweak) and 2.4.x (as-is), and I don't think the function
>>>> API issue is the major concern.  Instead, carrying the interpolation
>>>> expression around in the worker scheme field separate from an
>>>> interpolation flag seems to be the overriding issue.
>>>>> Dynamic determination of the scheme seems very useful and I don't know
>>>> of another way to implement the same requirement, which is well
>>>> illustrated by the now-broken config in the bug:
>>>>>       ProxyPassInterpolateEnv On
>>>>>       RewriteEngine On
>>>>>
>>>>>       RewriteCond %{HTTPS} =off
>>>>>       RewriteRule . - [E=protocol:http]
>>>>>       RewriteCond %{HTTPS} =on
>>>>>       RewriteRule . - [E=protocol:https]
>>>>>
>>>>>       ProxyPass /my_app/ ${protocol}://1.2.3.4/my_app/ interpolate
>>>>>       ProxyPassReverse /my_app/ ${protocol}://1.2.3.4/my_app/
>>>> interpolate
>>>>> Any alternate ideas for configuring something like that?
>>>>>
>>>>> Otherwise, any objections to patch 30799 (URL above)?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It is interesting that my research seems to indicate that mod_proxy
>>>> interpolation was actually the first to be introduced into the code.
>>>>> I guess the order is this:
>>>>>
>>>>> 1. support for environment variables in the config
>>>>> 2. mod_proxy interpolation
>>>>> 3. core server starts complaining if you have something that looks
>>>> like an envvar reference that isn't resolved
>>>>> Is that what you mean?
>>>>>
>>>>> The double use of ${} is nasty.  In the fullness of time, I think that
>>>> mod_proxy interpolation should support an additional syntax that doesn't
>>>> collide with the config-time processing.
>>>>> Yes, that is the point that I was trying to make.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mike Rumph
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Born in Roswell... married an alien...
>>>>> http://emptyhammock.com/
>>>
>>>
>>> -- 
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>


Mime
View raw message