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
