Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <36B33931-97E4-494F-AD78-FCA6A91DDB06@rescomp.stanford.edu>
From: Ian Ward Comfort <icomfort@rescomp.stanford.edu>
To: dev@httpd.apache.org
In-Reply-To: <ED1B5CFF-A892-47D3-BDA4-34D722E379E3@jaguNET.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Adding full environment variable support to mod_proxy_ajp
Date: Thu, 28 Aug 2008 12:23:57 -0700
References: <51223235-2972-4430-A47E-A0BC29DD86FF@rescomp.stanford.edu>
 <20080828111530.2525c3e7@grimnir>
 <ED1B5CFF-A892-47D3-BDA4-34D722E379E3@jaguNET.com>

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