Quoting [EMAIL PROTECTED]: > > <DirectoryIndex index.jsp index.vm> > > > > The order of events would be: > > > > 1. mod_dir does a sub request for index.jsp > > 2. jk_map_to_storage() receives the request > > 3. jk_map_to_storage() engages map_uri_to_worker() <-- this would be > > new code > > 4. map_uri_to_worker() finds nothing because it has no mapping to > > anything that > > matches *.jsp > > That's actually a problem - map_uri_to_worker would find a match ( > using *.jsp extension mapping ).
Sorry, I meant, but never wrote, that the problem would be if there was no explicit extension mapping. If there was, the match would be found and that wouldn't be one of the problem cases because we'd simulate r->finfo.filetype by setting it explicitly to APR_REG. Then mod_dir would engage the real request based on that with handler set to JK_HANDLER, which would then call Tomcat. > > Now, the next step is rather tricky and is the key to the whole thing. > > Does jk_map_to_storage(): > > > > a) assume that there is index.jsp in one of the mappings that match > > the URI minus the filename; jk_map_to_storage() could be very wrong about > > this > > - maybe there is a default file there, but not index.jsp - this would then > > result in a failed request > > If jk_map_to_storage finds an exact or prefix mapping - then the > problem is solved, the request goes to tomcat. Well, yes, but at this stage we are not doing the request. mod_dir is just checking if the request should go there or not. And since the real request would be originated by mod_dir, which filename would mod_dir use: index.jsp or index.vm? That would be a real problem case, I think. > If it finds an extension mapping - I have no idea. > > If it doesn't find any mapping - then it's not a request for tomcat > and you can look for static files ( or let mod_dir do it ). > > > So, one cannot 'go back' and do all > > this again, unless mod_dir is changed to do this kind of thing twice > > (which is definitely a bad idea). > > No, you don't need to go back. For each attempted index you make a > subrequest and you need to determine if tomcat could handle it. You mean here like this? Following code from mod_dir: --------------- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); --------------- Wouldn't that just end up going through jk_map_to_storage() again? > > If my old kludge is applied (with the correct test this time) to > > jk_handler(), > > things might be better. The kludge involved jk_handler() responding > > not just to > > JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, > > jk_handler() would > > find the mapping (since the request is for a directory, not a file) > > and the > > request would be served by Tomcat. > > I think this would work and is the best short-term solution. > > If it is a DIR, let tomcat serve it for now. I can implement that easily. But there is one catch: static files would get checked first (through the code in jk_map_to_storage()) and if the match wasn't found (either because there is no DirecoryIndex or there were no physical files that Apache can find), the the raw directory would hit jk_handler(). Is that a problem? Bojan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
