And I answer (to myself :-)
On Tue, 2002-07-23 at 14:47, Bojan Smojver wrote:
> So, the unsolved questions for me are:
>
> 1. What is it then that jk_handler() does that makes it actually serve the
> request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping
> is 'better' than mapping of jk_translate()...
Nothing special - it just does it ALWAYS. Which means that Tomcat ALWAYS
gets involved, which is NOT what Bill wanted (sorry Bill) and is
definitely not what I wanted. In order to fix that and let Apache handle
the directories it can physically see, and give the rest to Tomcat, we'd
need to do this at the beginning of jk_handler():
-----------------------------
/* Deciding if this request is for us, or should we pass it on */
if(strcmp(r->handler,JK_HANDLER)){
if(strcmp(r->handler,DIR_MAGIC_TYPE)) /* Not directory, skip */
return DECLINED;
else if(ap_is_directory(r->pool, r->filename)) /* Can stat, skip */
return DECLINED;
}
-----------------------------
Which would then mean that you MUST have DirectoryIndex in place if you
have extension mappings and want your physically accessible files served
by Tomcat. It would also mean that all physically accessible
directories, without ANY index files mentioned in DirectoryIndex, would
be served by Apache. Anything else would go to Tomcat for resolution.
This is not ideal and maybe not even correct, but it is the best I can
come up with at this point.
Before I make any changes to the CVS, I'd like to know what everyone
thinks. So, here are the choices:
[ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat
[ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off
[ ] Remove DIR_MAGIC_TYPE handling altogether
[ ] Make the change
[ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off
> 2. Or is it that jk_translate() never even gets involved during that request and
> therefore never has the chance to do the mapping?
I answered this one before. The request with DIR_MAGIC_TYPE never
touches jk_translate().
Bojan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
