You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/04/22 22:46:11 UTC

DO NOT REPLY [Bug 34584] New: - Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server

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: Carlos.Devoto@compuware.com


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org