On 05/28/2006 03:18 PM, Jeff Trawick wrote:
> On 5/27/06, Ruediger Pluem  wrote:
>> On 05/27/2006 03:58 PM, Jeff Trawick wrote:
>> >
>> > Are there still fundamental pieces missing from mod_proxy_ajp +
>> > mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
>> > the natural solution for anybody on Apache >= 2.2?
>> Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do
>> not know if this is regarded as fundamental piece.

Other things I noticed that are different:

1. mod_jk's recycle_timeout and cache_timeout are not exactly matched by 
   smax and ttl. But from my current personal point of view this does not 

2. mod_proxy_ajp does miss mod_jk's secret options. Again not critical from my 
point of view.

3. Currently connections are not checked if they are healthy *before* a request 
is send
   (something like mod_jk's connect_timeout, prepost_timeout). I think this 
would be nice to have,
   but I guess it is not easy to do this in a protocol independent way. So this 
might be only
   subject to implementation in mod_proxy_ajp.

4. There is no match for mod_jk's recovery_options currently. Furthermore I 
think some research
   needs to be done about mod_proxy's current behaviour in this situation. I 
guess this is important
   to prevent things being twice in your basket :-).

>> > Isn't pass-through of client SSL connection information another
>> > problem with mod_proxy?  (servlets can't access cipher or client
>> > certificate)
>> AFAIK not with mod_proxy_ajp. It seems to pass all these information
>> to Tomcat.
> oops, I meant "... problem with using generic HTTP support with
> mod_proxy -- mod_proxy_http"; I agree, the functional problem doesn't

I do not know if there is any standard in passing such information to the 
via HTTP, but I think you can pick up all SSL information that is available as 
variables and add them as request headers to the backend request via 
Is this a sufficient solution for the problem?

Regarding mod_proxy_http the following TODO's come up to my mind:

1. Currently we cannot handle keepalive connections to SSL backends.
2. There are some problems if the backend closes a keepalive connection by 
   due to a timeout. See also:


  and PR3770 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37770).



Reply via email to