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 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 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: http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/[EMAIL PROTECTED] and PR3770 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37770). Regards RĂ¼diger