RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c

2001-01-23 Thread James Courtney
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 23, 2001 8:52 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c Hi Jamey, You are touching a very important subject in th

RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c

2001-01-23 Thread cmanolache
Hi Jamey, You are touching a very important subject in the mod_jk implementation. And YES, you are absolutely right ( IMHO ) - Apache, IIS, NES, AOLServer are pretty good at processing requests - after all that's their main business. Each requests is mapped by the ( optimized ) mappers of the nat

Re: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c

2001-01-22 Thread Geoff Soutter
day, January 23, 2001 5:43 PM Subject: RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c > Many thanks, > I was wondering why both the mod_jk module and IIS isapi act as filters > instead of an Apache handler or an IIS application respectively. In their > current

RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c

2001-01-22 Thread James Courtney
Many thanks, I was wondering why both the mod_jk module and IIS isapi act as filters instead of an Apache handler or an IIS application respectively. In their current implementation they scan all request URIs for ones that they are responsible for and then, in the case of Apache anyway, r