Would it also make sense to put that info into r->notes ? On Sep 17, 2013, at 9:23 AM, Jeff Trawick <[email protected]> wrote:
> On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph <[email protected]> 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/
