DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34584>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34584 Summary: Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server Product: Tomcat 5 Version: 5.0.7 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: major Priority: P1 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Many commercial/non-commercial web products lay down Tomcat as an out-of-the- box servlet container when they are installed. For Windows customers, such products also often configure an instance of the JK ISAPI filter/extension to IIS (isapi_redirect.dll). Unfortunately, the /jakarta-tomcat- connectors/jk/native/iis/isapi_redirect_plugin.c module is written in such a way that only one instance of the JK ISAPI filter/extension will function properly per instance of IIS. When you have two or more filters/extensions configured within IIS, only the final filter in the filter chain functions properly. The other filters kick out Tomcat 404 errors for all request URIs that match the URL patterns in the corresponding uriworkmap.properties file. As a developer for Compuware Corporation, I recently took it upon myself to resolve this issue. Because I am working behind an authenticating firewall, I cannot connect my CVS client to your CVS repositories in order to create a patch file, as recommended by your contribution guidelines. I have nevertheless resolved the issue by adding a single line to the /jakarta- tomcat-connectors/jk/native/iis/isapi_redirect_plugin.c file as shown below: diff -r1.2 -r1.3 23c23 < * Version: $Revision: 1.2 $ * --- > * Version: $Revision: 1.3 $ * 903a904 > return SF_STATUS_REQ_HANDLED_NOTIFICATION; My analysis of the problem revealed that when a given instance of the JK ISAPI filter finds that a request URI matches one of the URL patterns in its map, it redirects to the proper JK ISAPI extension, but it also passes the request along to the next filter in the chain. This is what is causing the problem. When a match is found by one filter, the redirection should go directly to the extension without going through the other filters further down the chain. This can be achieved by returning SF_STATUS_REQ_HANDLED_NOTIFICATION from the HttpFilterProc function instead of SF_STATUS_REQ_NEXT_NOTIFICATION whenever a URI match is found. I have tested this fix by installing three separate instances of Tomcat, each with its own corresponding JK ISAPI filter/extension. I did this on Windows 2000 Server, Windows 2003 Server, and Windows XP professional. In every case, all three instances of the JK ISAPI filter/extension worked properly. The first filter to find URI pattern match handles the request by routing to the corresponding extension. This fix will yield significant savings for my company in terms of time and money spent on support calls, and I believe that other Tomcat redistributors will benefit from it as well. I therefore hope that you will incorporate this change, or one similar to it, into your codebase for the Tomcat JK Connector. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]