You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Ward Comfort <ic...@rescomp.stanford.edu> on 2008/08/28 08:53:24 UTC
Adding full environment variable support to mod_proxy_ajp
My environment is affected by bug 40047, the lack of a mod_proxy_ajp
equivalent to mod_jk's JkEnvVar directive. (The mod_rewrite gyrations
required to work around this with AJP_* vars are too unpleasant to
maintain.) If I write a patch for this feature, might it stand a
chance of upstream inclusion? If so, thoughts on the following would
be appreciated.
* The directive should probably be handled by mod_proxy. It may be
relevant to protocols besides AJP, and mod_proxy already has
configuration objects, unlike mod_proxy_ajp.
* A lot of the code can probably be reused from mod_jk, unless anyone
foresees a problem with this.
* What's an appropriate name for the directive -- ProxyEnvVar?
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On 28 Aug 2008, at 12:23 PM, Ian Ward Comfort wrote:
>
> [...]
Any further thoughts on this thread? If not, I'll take a stab at a
patch and cross my fingers re: inclusion.
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Mladen Turk <mt...@apache.org>.
Ian Ward Comfort wrote:
>>
>> There isn't a problem with new directives. I merely suggested an
>> alternative that I think makes sense in this instance. Evidently not
>> everyone agrees. Bottom line: if you're doing the work, then you
>> decide what approach you prefer.
>
> Fair enough. I'll keep an open mind in case a better suggestion
> appears, and otherwise do something that works here.
>
Right now mod_proxy_ajp passes from r->subprocess_env all
key/val pairs having AJP_ prefix and stripping that prefix.
So one needs basically a duplicate value.
In your example
WEBAUTH_LDAP_DISPLAYNAME=foo
needs to be duplicated to
AJP_WEBAUTH_LDAP_DISPLAYNAME=foo
The solution might be to mark the
envvar so it gets evaluated at runtime
either as:
AJP_WEBAUTH_LDAP_DISPLAYNAME=${WEBAUTH_LDAP_DISPLAYNAME}
or even generic both for mod_proxy_http and mod_proxy_ajp
PROXY_WEBAUTH_LDAP_DISPLAYNAME=${WEBAUTH_LDAP_DISPLAYNAME}
So:
SetEnv PROXY_WEBAUTH_LDAP_DISPLAYNAME ${WEBAUTH_LDAP_DISPLAYNAME}
would cause to strip the PROXY_ from the r->subprocess_env and
use value from ${XX} again from r->subprocess_env.
Some other notion could be used of course, eg.
SetEnv PROXY_FOO
without a value (empty) could just use the FOO's value.
Regards
--
^(TM)
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On 4 Sep 2008, at 2:54 AM, Nick Kew wrote:
> But if we're talking about the backend's env, then (optionally)
> inheriting it from the proxy seems to me to make semantic sense.
There is a logic to that strategy. I for one rarely need the whole
environment forwarded, and would probably rather not take the
performance hit for the sake of logic. (Reality interferes with clean
design again.)
> On Thu, 4 Sep 2008 02:00:47 -0700 Ian Ward Comfort <icomfort@rescomp.stanford.edu
> > wrote:
>> To me, 'ProxyEnvVar REMOTE_USER' is succinct and effective.
>
> I'd say quite the reverse! REMOTE_USER is not normally an env var.
> It only becomes one if a consumer of the CGI env is in operation.
> In the case of a proxy, that means mod_rewrite, mod_include, or
> third-party module. That'll truly confuse the users!
A poorly chosen example, then -- let's say 'ProxyEnvVar
WEBAUTH_LDAP_DISPLAYNAME'. (I meant only that a ProxyEnvVar directive
made sense to me.)
>> But if new directives are anathema, I'm willing to implement a
>> different interface, if a suitable one can be found.
>
> There isn't a problem with new directives. I merely suggested an
> alternative that I think makes sense in this instance. Evidently
> not everyone agrees. Bottom line: if you're doing the work, then
> you decide what approach you prefer.
Fair enough. I'll keep an open mind in case a better suggestion
appears, and otherwise do something that works here.
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 4 Sep 2008 02:00:47 -0700
Ian Ward Comfort <ic...@rescomp.stanford.edu> wrote:
> > I think, that forwarding the full subprocess_env table is to much
> > and usually not what is needed.
But if we're talking about the backend's env, then (optionally)
inheriting it from the proxy seems to me to make semantic sense.
> > If you really have use cases, where there are lots of env vars you
> > want to forward, you could think about allowing patterns on the
> > variable names. That would make administration less tedious but of
> > course sacrifice performance a bit.
There's a precedent for that, with CGI (and all its followers) using
HTTP_[foo] for presenting HTTP headers to a backend's env.
> I could do without patterns. It's not the number of variables
> that's a problem for me, it's that config lines like the above are
> too easy to screw up. (Plus I'd rather not have to worry about
> interaction with rules I might use to do actual URL rewriting.)
>
> To me, 'ProxyEnvVar REMOTE_USER' is succinct and effective.
I'd say quite the reverse! REMOTE_USER is not normally an env var.
It only becomes one if a consumer of the CGI env is in operation.
In the case of a proxy, that means mod_rewrite, mod_include, or
third-party module. That'll truly confuse the users!
> But if
> new directives are anathema, I'm willing to implement a different
> interface, if a suitable one can be found.
There isn't a problem with new directives. I merely suggested an
alternative that I think makes sense in this instance. Evidently
not everyone agrees. Bottom line: if you're doing the work, then
you decide what approach you prefer.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On 4 Sep 2008, at 1:48 AM, Rainer Jung wrote:
> Ian Ward Comfort wrote:
>> RewriteRule ^ - [C,E=AJP_REMOTE_USER:%{ENV:REMOTE_USER}]
>
> I think, that forwarding the full subprocess_env table is to much
> and usually not what is needed.
I agree.
> If you really have use cases, where there are lots of env vars you
> want to forward, you could think about allowing patterns on the
> variable names. That would make administration less tedious but of
> course sacrifice performance a bit.
I could do without patterns. It's not the number of variables that's
a problem for me, it's that config lines like the above are too easy
to screw up. (Plus I'd rather not have to worry about interaction
with rules I might use to do actual URL rewriting.)
To me, 'ProxyEnvVar REMOTE_USER' is succinct and effective. But if
new directives are anathema, I'm willing to implement a different
interface, if a suitable one can be found.
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Rainer Jung <ra...@kippdata.de>.
Ian Ward Comfort wrote:
> On 2 Sep 2008, at 9:34 PM, Mladen Turk wrote:
>> Anyhow I agree with Nick that using existing directives from
>> mod_rewrite or mod_headers would be much nicer solution, so I'm not in
>> favor of adding new directives.
>
> Do you like the idea of proxying the entire subprocess_env table, or
> have another suggestion? Personally, I'd like to avoid loading
> mod_rewrite in my environment, and a long list of these is neither
> efficient nor pleasant to maintain:
>
> RewriteRule ^ - [C,E=AJP_REMOTE_USER:%{ENV:REMOTE_USER}]
I think, that forwarding the full subprocess_env table is to much and
usually not what is needed. If you really have use cases, where there
are lots of env vars you want to forward, you could think about allowing
patterns on the variable names. That would make administration less
tedious but of course sacrifice performance a bit.
Regards,
Rainer
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On 2 Sep 2008, at 9:58 PM, William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Basically if you add additional config directive it cannot be
>> backported.
>
> Cannot isn't quite fair... it simply makes it less likely to be
> accepted. Essentially you ask yourself, is this fixing a bug or
> problem with 2.2, or is it a new feature that should be added and
> instead of distracting the devs from releasing 2.4.0, should the
> emphasis be on getting the new version released?
OK, it sounds like I should give up on the 2.2 backport anyway, which
is fine. (It's easy enough for me to backport and apply locally if I
need it.) And in that case, there's no rush on this feature, so the
devs can decide their own priorities regarding 2.4.0.
I would like to write something that others can/will use, if possible.
On 2 Sep 2008, at 9:34 PM, Mladen Turk wrote:
> Anyhow I agree with Nick that using existing directives from
> mod_rewrite or mod_headers would be much nicer solution, so I'm not
> in favor of adding new directives.
Do you like the idea of proxying the entire subprocess_env table, or
have another suggestion? Personally, I'd like to avoid loading
mod_rewrite in my environment, and a long list of these is neither
efficient nor pleasant to maintain:
RewriteRule ^ - [C,E=AJP_REMOTE_USER:%{ENV:REMOTE_USER}]
I don't see a way to extend mod_headers for this, but I might be
missing something.
(Also, for my own understanding, what are the primary concerns about
new directives? Namespace pollution?)
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> Ian Ward Comfort wrote:
>>
>> I don't think I understand the API versioning issues, but the
>> possibility of a 2.2 backport would make me happy. :)
>>
>
> Basically if you add additional config directive it cannot
> be backported. Anyhow I agree with Nick that using existing
> directives from mod_rewrite or mod_headers would be much
> nicer solution, so I'm not in favor of adding new directives.
Cannot isn't quite fair... it simply makes it less likely to be
accepted. Essentially you ask yourself, is this fixing a bug or
problem with 2.2, or is it a new feature that should be added
and instead of distracting the devs from releasing 2.4.0, should
the emphasis be on getting the new version released?
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Mladen Turk <mt...@apache.org>.
Ian Ward Comfort wrote:
>
> I don't think I understand the API versioning issues, but the
> possibility of a 2.2 backport would make me happy. :)
>
Basically if you add additional config directive it cannot
be backported. Anyhow I agree with Nick that using existing
directives from mod_rewrite or mod_headers would be much
nicer solution, so I'm not in favor of adding new directives.
Regards
--
^(TM)
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On 28 Aug 2008, at 3:15 AM, Nick Kew wrote:
> How big is this proposed patch? A patch that can be reviewed in
> five minutes has a lower barrier to inclusion than one that a
> developer has to spend all day reviewing :-)
At the moment, it's just hypothetical, but mod_jk implements JkEnvVar
in about 100 lines. Then there's documentation, of course.
> Anyway, as an alternative to your proposal, would it fix your
> problem if variables set using SetEnv or PassEnv - or dynamically
> using mod_rewrite - were propagated to the backend appserver?
If it were strictly limited to variables set this way -- no, since we
also require the propagation of variables set by custom modules
(mod_webauthldap). Propagating the entire subprocess_env table might
work for us...
On 28 Aug 2008, at 6:21 AM, Jim Jagielski wrote:
> I think we would want some sort of control over which vars are and
> aren't passed back, so I don't see how we could get around not
> having another set of directives
... but I agree that in general one wants independent control over
variables exported to CGI scripts versus variables sent to proxy
backends.
> Even so, this seem more an enhancement for mod_env than mod_proxy
> (although mod_proxy would be the prime user :) )
Hmm, you may be right. Unless we can think of another consumer for
this information, though, I think mod_proxy might be the right place.
The data would sit unused if mod_proxy weren't loaded, and mod_proxy
would have to check for mod_env and possibly fiddle with its data
structures. FWIW, we don't load mod_env.
> But, this means, afaict with a quick glance, that some minor API
> bumps would be needed (at least) so maybe doing it in mod_proxy
> would be an easier pill to swallow (esp for anything hoped to be
> backported to 2.2).
I don't think I understand the API versioning issues, but the
possibility of a 2.2 backport would make me happy. :)
--
Ian Ward Comfort <ic...@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 28, 2008, at 6:15 AM, Nick Kew wrote:
> On Wed, 27 Aug 2008 23:53:24 -0700
> Ian Ward Comfort <ic...@rescomp.stanford.edu> wrote:
>
>> My environment is affected by bug 40047, the lack of a mod_proxy_ajp
>> equivalent to mod_jk's JkEnvVar directive. (The mod_rewrite
>> gyrations required to work around this with AJP_* vars are too
>> unpleasant to maintain.) If I write a patch for this feature, might
>> it stand a chance of upstream inclusion? If so, thoughts on the
>> following would be appreciated.
>>
>> * The directive should probably be handled by mod_proxy. It may be
>> relevant to protocols besides AJP, and mod_proxy already has
>> configuration objects, unlike mod_proxy_ajp.
>>
>> * A lot of the code can probably be reused from mod_jk, unless
>> anyone foresees a problem with this.
>>
>> * What's an appropriate name for the directive -- ProxyEnvVar?
>
> How big is this proposed patch? A patch that can be reviewed in
> five minutes has a lower barrier to inclusion than one that a
> developer has to spend all day reviewing :-)
>
> Anyway, as an alternative to your proposal, would it fix your
> problem if variables set using SetEnv or PassEnv - or dynamically
> using mod_rewrite - were propagated to the backend appserver?
> If so, I'd think that a nicer solution than a new directive.
I think we would want some sort of control over which vars are
and aren't passed back, so I don't see how we could get around not
having another set of directives (unless we do something hankie
like PassEnv & FOO_HOO_BOO_HOO where the '&' means all envars
after the '&' should get passed thru)...
Even so, this seem more an enhancement for mod_env than mod_proxy
(although mod_proxy would be the prime user :) ) But, this
means, afaict with a quick glance, that some minor API bumps would
be needed (at least) so maybe doing it in mod_proxy would be an
easier pill to swallow (esp for anything hoped to be backported
to 2.2).
Re: Adding full environment variable support to mod_proxy_ajp
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 27 Aug 2008 23:53:24 -0700
Ian Ward Comfort <ic...@rescomp.stanford.edu> wrote:
> My environment is affected by bug 40047, the lack of a mod_proxy_ajp
> equivalent to mod_jk's JkEnvVar directive. (The mod_rewrite
> gyrations required to work around this with AJP_* vars are too
> unpleasant to maintain.) If I write a patch for this feature, might
> it stand a chance of upstream inclusion? If so, thoughts on the
> following would be appreciated.
>
> * The directive should probably be handled by mod_proxy. It may be
> relevant to protocols besides AJP, and mod_proxy already has
> configuration objects, unlike mod_proxy_ajp.
>
> * A lot of the code can probably be reused from mod_jk, unless
> anyone foresees a problem with this.
>
> * What's an appropriate name for the directive -- ProxyEnvVar?
How big is this proposed patch? A patch that can be reviewed in
five minutes has a lower barrier to inclusion than one that a
developer has to spend all day reviewing :-)
Anyway, as an alternative to your proposal, would it fix your
problem if variables set using SetEnv or PassEnv - or dynamically
using mod_rewrite - were propagated to the backend appserver?
If so, I'd think that a nicer solution than a new directive.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/