httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Ward Comfort <icomf...@rescomp.stanford.edu>
Subject Re: Adding full environment variable support to mod_proxy_ajp
Date Thu, 28 Aug 2008 19:23:57 GMT
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 <icomfort@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University


Mime
View raw message