On 07 September 2004, Endre St?lsvik said: > The mod_jk approach of inventing a new binary protocol and whatnot is > maybe not the right solution for this. A simple raw forwarding of the > requests from Apache HTTPD to Apache Tomcat would be incredibly nice.
Do what I did: try to replace mod_jk with mod_proxy. Do this on a server where some requests are SSL and some are not, and where redirects (eg. "/foo" -> "http://www.example.com/foo/";) need to work, and you'll start to understand (like I did) why the AJP protocol exists: * to forward both SSL and non-SSL requests with mod_proxy, you'd need two HTTP connectors in Tomcat, meaning two thread pools * to handle server-generated redirects (which includes response.sendRedirect() calls in your webapps), you need to ensure that Tomcat knows the name of the server as seen by clients -- in our environment (hundreds of servers to administer worldwide behind NAT firewalls with poor DNS control), this is rather tricky, and would most likely mean generating server.xml when Tomcat starts up. (No, we don't handle this very well with Apache either, but at least we don't need to dynamically generate httpd.conf -- we just include a servername.conf file that's generated when Apache's config files are installed on that server.) Once I hit those two stumbling blocks, I backed off and decided to live with mod_jk for a while longer. (They're not insurmountable, but I have better things to do with my time.) Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
