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 Wed, 04 Sep 2013 21:12:03 GMT
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

Mime
View raw message