tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Date Mon, 22 Jul 2002 05:23:48 GMT

----- Original Message -----
From: "Bojan Smojver" <>
To: "Tomcat Developers List" <>
Sent: Sunday, July 21, 2002 9:19 PM
Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2

> Quoting
> > You don't need to ask tomcat - jk should have all the mappings, and
> > it can already map any URI. All it has to do is:
> > - for each index:
> >     -- concatenate with the current uri
> >     -- do the jk mapping ( or internal redirect if you use <Location>
> > instead of the internal mapper ). If a match is found - forward to
> > tomcat.
> >     -- check if a file exists. If yes - serve it as static ( since
> > we already checked all servlet mappings ).
> > - if no match is found, use mod_dir to display the directory.
> Just reading the algorithm and thinking about the implementation of it.
Some of
> the things might present themselves as big problems here in relation to
> mappings...
> An example configuration:
> <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
> 4. map_uri_to_worker() finds nothing because it has no mapping to anything
> matches *.jsp
> Now, the next step is rather tricky and is the key to the whole thing.
> jk_map_to_storage():
> a) assume that there is index.jsp in one of the mappings that match the
> minus the filename; jk_map_to_storage() could be very wrong about this -
> there is a default file there, but not index.jsp - this would then result
in a
> failed request
> b) continue processing with the next index file (in this case index.vm)
> possibly miss both index.jsp and index.vm in one of the servlet mappings
> Keep in mind that these are sub-requests that don't actually result in the
> being served. It's just mod_dir's  way of checking what would happen if
> was a file like that 'in the file system'. So, one cannot 'go back' and do
> this again, unless mod_dir is changed to do this kind of thing twice
(which is
> definitely a bad idea).
> I actually think that it is not possible to establish if there is such a
> unless mod_jk somehow knows about their exisitence. I'm not all that
> with mappings, but I reckon that isn't the case.
> And then, when everybody thought all was lost... ;-)
> If my old kludge is applied (with the correct test this time) to
> 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()
> find the mapping (since the request is for a directory, not a file) and
> request would be served by Tomcat.
> Would this work? I think it might...

At the moment, the servlet-mapping issue is somewhat of a red-herring, since
only 3.3.2-dev supports it (and even there, it is disabled by default).  For
now, mod_jk(2) might as well assume that the physical jsp/vm file is there,
since Tomcat requires that it is.  The real issue is that jk_map_to_storage
was a kludgy attempt to bypass tree-walking by Apache (and save the time to
do all of those stat calls).  Your fix at least removes the "kludgy" part.

I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat,
since I tend to set up directories with only static content that only Apache
knows about.  Sending them to Tomcat just gives me very many 404 errors, so
I'd be forced to use a branched copy of mod_jk.

If you have:
JkMount /myapp/*.jsp ajp13
JkMount /myapp/*.vm ajp13

Then jk_translate will grab the request for /myapp/index.jsp and set the
handler.  If the file is physically there, then jk_map_to_storage will stat
it, and everyone is happy.  Otherwise, jk_translate will grab the request
for /myapp/index.vm and set the handler and do the same check for a physical

In Apache 1.3.x, this is basically what happens except that the "physical
file" test is done by Apache's tree-walk.

> Bojan
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message