On Sun, 21 Jul 2002 [EMAIL PROTECTED] wrote:
> 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
In Servlet 2.4 (Community Draft 2), it looks like the language in Section
9.10 that describes this hasn't changed. The basic rule is that you
combine the "partial URLs" specified in the welcome file list to the
incoming request for a "directory" resource in the WAR -- and if "a
resource in the WAR is mapped that request URI" then it's supposed to be
served by the servlet corresponding to the complete request URI.
> 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
Catalina interprets the requirement as meaning that there has to be a
static resource that matches. This has the side effect that you can't use
a regular servlet mapping that doesn't correspond to a static resource --
if you could, that would mean that a welcome file like "foo.jsp" would
match every time, even if there wasn't such a page in the specified
directory, because of the "*.jsp" mapping.
It would seem that a web connector should at least be able to emulate what
Catalina does, by checking for the existence of a static file in the
> ( 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 ?
I don't know how you could implement a generic servlet matching a "welcome
file" path, unless we were to exclude extension mapping and default
servlet from the definition of "matching". And I'm not sure that even
that would do the right thing in all circumstances.
> > 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]>
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>