The current JK/ISAPI redirector uses 4 special headers to pass redirector information from the FilterProc to the ExtensionProc. These are cleared in the FilterProc prior to attempting a match on the incoming URL. Since IIS passes requests through all the filters, any JK/ISAPI redirector in the ISAPI Filters stack that is below the matching redirector will cause the headers to be cleared and the request to fail. A common deployment scenario for our products is to use a single web customer website (running on port 80) with multiple virtual directories and ISAPI redirectors - one for each product in the deployed solution. I'm aware that the mod_jk config is geared towards a single redirectory with a single config file, but even our Apache sites use multiple virtual hosts with separate mod_jk configs. It's not immediately obvious if there's actually a benefit in clearing the headers. If someone wanted to spoof these, then they could talk directly to the ExtensionProc anyway, and you can ensure they're set correctly just by being careful in the FilterProc. The offending lines in jk_isapi_plugin.c r1.49, lines 749..755 /* * Just in case somebody set these headers in the request! */ SetHeader(pfc, URI_HEADER_NAME, NULL); SetHeader(pfc, QUERY_HEADER_NAME, NULL); SetHeader(pfc, WORKER_HEADER_NAME, NULL); SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL); We've used two solutions to this successfully in internal builds: 1. Don't clear the headers 2. Unique URI_HEADER_NAME et al during the redirector load i.e. using the extension_uri or the DLL process ID.
Isapi filter is supposed to have a Highest level and be the first filter in the ISAPI filter chain.
The problem I've noted is that you can't have multiple Tomcat ISAPI redirectors on a single IIS site, not the order or priority. This is a practice that we use a lot, to avoid having to merge multiple redirector configs when installing multiple products on a single server. This isn't an issue for mod_jk, as it's a simple include, but IIS as usual requires you to do a lot of the work yourself. This is a fairly minor thing to work around in the redirector, and I'd be happy to contribute a patch to do it. If it's absolutely not a possibility for the main branch, then we can maintain our own, but I think it's a feature worthy of inclusion in the core Jakarta tree.
Created attachment 15583 [details] Multiple redirectors per IIS Website This patch uniques the headers used by the redirector to pass information between FilterProc and ExtensionProc by mixing in the DLL handle.
Commited. Thanks!
I've reviewed this again, and there's still a problem or two. The main one is that there's a magic tmp += 6 in init_ws_service which is meant to skip the TOMCAT bit of the header name to leave TRANSLATE in the buffer to be used as the HTTP header name. Generating the headers as we do now will break this. I've reworked it to make it obvious what is happening. In the process of fixing this, I also tidied a bit of the header handling and rejigged the HTTP_ header generation to share a prefix with the code in init_ws_service.
Created attachment 16478 [details] Fixes for Tomcat Header Handling Patch against jk_isapi_redirect.c r1.53 to fix problems introduced by uniquing TOMCAT headers + a few tidies of the header handling code.
Hi, Can you create a patch that fixes the problem with Translate only. Although I agree that your changes make sense the number of changes is big and unrelated to the problem itself. You might then create a second patch that will have fixed sizes instead strlen, etc...
Created attachment 16484 [details] Fixes for Tomcat Header Handling (Minimal) Redone patch to fix only the TRANSLATE header handling bug.
Commited a second patch. Thanks. The full patch is syntatic sugar, so we'll keep that for the future.