On Wed, 25 Jun 2003, Palle Girgensohn wrote: > setup: > > FreeBSD 4.8-RELEASE, apache 1.3.27 w/ mod-ssl 2.8.14, mod_jk 1.2.3 and > 1.2.4. Tomcat version is irrelevant since the request never leaves apache, > but anyway, it is tomcat 3.3.1a. > > JkMount /pp/system/*jsp > > [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (460)]: Into > jk_uri_worker_map_t::map_uri_to_worker > [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (477)]: Attempting to map > URI '/pp/entrance/login.jsp' > [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (558)]: > jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match tomcat -> *.jsp > [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (460)]: Into > jk_uri_worker_map_t::map_uri_to_worker > [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (477)]: Attempting to map > URI '//pp/entrance/login.jsp' > [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (599)]: > jk_uri_worker_map_t::map_uri_to_worker, done without a match > > map_uri_to_worker just makes an exact match, in my case "//pp/system" > against "/pp/system/", actually on line 485: > > if(0 == strncmp(uwr->context, > uri, > uwr->ctxt_len)) { > > double slashes after /pp/system/ are OK, they will be sent on to tomcat, > which has code to handle this.
This reflects a design problem in mod_jk. Instead of using Apache's support for <Directory> sections and handlers, it attempts to reimplement it on its own. This is one example of where it doesn't work and exposes a security issue. There are a lot of other examples, especially on windows, where there is a lot of filename variance. When you are "protecting" (in this case, by forwarding to something else to handle them) files, you will expose yourself to a wide variety of security holes if you attempt to do so based on URI instead of on the canonical version of the path. There is a related problem in mod_jk2 that I ran into, which results in breaking any attempt to use a DirectoryIndex setting with "index.jsp" or some such in it. If you configure mod_jk2 to handle *.jsp, it assumes that if you get a request for "foo.jsp" then tomcat should handle it even if foo.jsp doesn't exist, so it sends the request to tomcat even if there is no such file. Same underlying cause: trying to dispatch based on parsing the URI instead of using Apache's built in support for doing such things in a more graceful and robust manner. Even more horrible is the fact that mod_jk2 lets you enclose things in Location sections such as: <Location "/*.jsp"> JkUriSet group ajp13:worker1 </Location> ...only it uses some horrible hacked up kludge to actually parse the argument to the Location itself. Even though this is a "Location" directive, because of mod_jk2's very odd design the arguments are interpreted completely differently from how Apache does, which leads to all sorts of chaos. If I recall correctly, and I haven't checked for a few months, I think there are some comments in the mod_jk2 code indicating that support for using it as an Apache handler was removed because the person hacking on it didn't understand why it is necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]