On Mon, 22 Jul 2002, Bojan Smojver wrote:

> > it can already map any URI. All it has to do is:
> > - for each index: 
> Just reading the algorithm and thinking about the implementation of it. Some of

Well, don't take it as an algorithm - there are many other things to 

> <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 ).

That's very serious - need to check the servlet specs, maybe 2.4 has more 

I'm not sure how tomcat deals with that - we would find the extension 
mapping and find the JspServlet which is mapped to it. But there 
is no way to tell if this is a real match or not - without invoking

( well, for JSPs we know that a file may be there, but what if the 
extension would be for something else ? )

Craig, Remy - any ideas ?

> 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. 

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 ).

> Keep in mind that these are sub-requests that don't actually result in the file
> being served. It's just mod_dir's  way of checking what would happen if there
> was a file like that 'in the file system'. 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. 

Assuming jk has knowledge about all the mappings in web.xml - you can
do that ( again, I don't know how to deal with extension mappings ).

> 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. 


To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to