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
