Messages such as the following are logged: [Mon Sep 05 11:36:35 2011] [jk_isapi_plugin.c (843)]: HttpFilterProc [/integrator/download/d2b3b4c1-5eb2-4c45-9ca6-2af7bdc286e3/teamtrainer/50/meta-inf.xml;jsessionid=4adfb2366e39fef63fda294d375f0273] points to the web-inf or meta-inf directory. Somebody try to hack into the site!!! and HTTP status 403 is returned on the request. This is a false positive. The file name is meta-inf.xml but it is not in the meta-inf directory. A number of forum references can be found e.g. http://mail-archives.apache.org/mod_mbox/tomcat-dev/200505.mbox/%3C1115929838.4283bcee5ca60@aragorntools.webappcabaret.net%3E but it does appear to have been previously raised as a bug. Unfortunately this renders the ispai connector unusable with this Tomcat application. Reproduced on isapi at 1.2.32 (not available in pulldown list!). Cannot be reproduced in mod_jk connector.
Looks like jk_isapi_plugin.c::uri_is_web_inf is a little too liberal with it's check: static int uri_is_web_inf(const char *uri) { if (stristr(uri, "/web-inf")) { return JK_TRUE; } if (stristr(uri, "/meta-inf")) { return JK_TRUE; } return JK_FALSE; } Might make sense to check to see if the uri either ends with either of those two strings or explicitly has a "/" after either of them. Obviously, requesting "/anything/meta-info-for-my-application" would cause a failure, here. I can confirm that mod_jk does not enforce such checks, because without <Location>Allow/Deny</Location>, httpd will serve content out of WEB-INF and META-INF directories if an Alias is set up to point to the deployment directory.
Created attachment 27466 [details] Proposed fix to uri_is_web_inf function. I have neither a win32 compiler nor an IIS environment handy to compile and test this, so I'm attaching this as a patch in BZ instead of committing to trunk. If someone could test, that would be great.
Fixed in r1187916, will be part of version 1.2.33. I used a slightly different solution as Chris choosing to add another function as a replacement for stristr. Should be functionally equivalent. Regards, Rainer