httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject RE: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
Date Wed, 09 Oct 2013 07:35:17 GMT
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 <trawick@gmail.com><mailto:trawick@gmail.com>
wrote:



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

<ruediger.pluem@vodafone.com><mailto: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><mailto: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