On 19 Nov 2010, at 6:24 PM, Nick Kew wrote:
Most specifically, if SSLOptions +StdEnvVars is specified, the hook
gets called with the data, and an implementation writes them to the
subprocess environment, or headers_in, as appropriate (and as
configured).
A hook? That suggests you expect further generality!
Indeed I do, yes.
Why not just an alternative SSLOption to set headers_in in
place of subprocess_env?
Because as soon as you have two different ways of doing something, you
than need to ask yourself "but what if I want to do it a third way, or
a fourth way, or maybe some custom way unique to my application", and
you then come to the conclusion "why not provide a hook, so the admin
can configure it any way he wants, and it stops being httpd's problem
at all".
To explain more of where I am coming from.
We have ZXTM load balancers, which front various httpds that do
various things. We have client certificate protected connections to
the load balancers, which terminate the SSL, then establish a new
connection pool to the backend httpds (also SSL, but with different
certs).
In order to expose details of the original client certificate, ZXTM
injects many headers into the request, just as we inject CGI variables
into the subprocess environment. Applications behind in turn pick up
DNs and other details from these headers. The headers are ZXTM specific.
For various reasons we don't want to use ZXTMs for everything, and so
some httpds terminate the SSL themselves, however we face a problem:
no clean ZXTM compatible capability exists to expose the headers to
the backend.
Our first prize would be to develop for ourselves a
mod_ssl_zxtm_compat module, that when turned on would just send ZXTM
compatible headers, but we lack the hook to hook into.
Sure, we can try and kludge it, by trying to pick up and rewriting the
CGI variables, and then worrying that our module runs after the
mod_ssl module, or we can simply add twenty RequestHeader statements
next to each ProxyPass, but both of these scream "kludge", and
"kludge" is what we're trying to move away from.
Regards,
Graham
--
