httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Date Sun, 28 May 2006 20:59:53 GMT

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 mod_proxy's
   smax and ttl. But from my current personal point of view this does not matter.

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
   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 backend
via HTTP, but I think you can pick up all SSL information that is available as env
variables and add them as request headers to the backend request via mod_headers.
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 itself
   due to a timeout. See also:

  and PR3770 (



View raw message