httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: Adding full environment variable support to mod_proxy_ajp
Date Thu, 04 Sep 2008 09:54:37 GMT
On Thu, 4 Sep 2008 02:00:47 -0700
Ian Ward Comfort <> 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

View raw message