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/
