Re: Adding full environment variable support to mod_proxy_ajp
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
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
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 [EMAIL PROTECTED]
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
On Thu, 4 Sep 2008 02:00:47 -0700 Ian Ward Comfort [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
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 [EMAIL PROTECTED]
System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
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 [EMAIL PROTECTED] System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
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
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?
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 [EMAIL PROTECTED] System Administrator, Student Computing, Stanford University
Re: Adding full environment variable support to mod_proxy_ajp
On Wed, 27 Aug 2008 23:53:24 -0700 Ian Ward Comfort [EMAIL PROTECTED] 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/
Re: Adding full environment variable support to mod_proxy_ajp
On Aug 28, 2008, at 6:15 AM, Nick Kew wrote: On Wed, 27 Aug 2008 23:53:24 -0700 Ian Ward Comfort [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] System Administrator, Student Computing, Stanford University
