You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bojan Smojver <bo...@rexursive.com> on 2002/07/23 13:24:31 UTC
[VOTE]: Re: cvs commit:
jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs commit:
jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2002-07-23 at 23:39, Henri Gomez wrote:
> > 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
>
> For someone who have all its tomcat behind a webserver, I'll be to have the
> requests sent to Tomcat since my web servers won't have a directory created for
> all the webapps available on tomcats farms behind.
If you don't have the directories that Apache can see, then this latest
change would still work for you (i.e. anything that is not an explicit
index page like index.jsp or a directory goes to Tomcat). So, I'm
guessing this would be a vote for 'Make the change'.
> Alternativly I don't want to receive index.php or index.pl in Tomcat, and so
> want only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount
> *.jsp ajp13.
That would be handled by Apache anyway through the usual DirectoryIndex
machinery, so no problems there.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Henri Gomez <hg...@apache.org>.
Quoting Bojan Smojver <bo...@rexursive.com>:
> 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().
For someone who have all its tomcat behind a webserver, I'll be to have the
requests sent to Tomcat since my web servers won't have a directory created for
all the webapps available on tomcats farms behind.
Alternativly I don't want to receive index.php or index.pl in Tomcat, and so
want only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount
*.jsp ajp13.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs
commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2002-07-24 at 18:26, Henri Gomez wrote:
> > > I can live with any but the first. It would be nice to have it as a
> > config
> > > option however. JkOptions is probably fine for 1.2. Not sure where it
> > > should be set in Jk2.
> >
> > Thanks. I'm not sure about mod_jk2 either. The latest reports show that
> > the code still doesn't work.
>
> Great to have it in jk 1.2.x.
>
> BTW, what's the default behaviour ?
Default is to let Apache do it's thing.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Henri Gomez <hg...@apache.org>.
> > I can live with any but the first. It would be nice to have it as a
> config
> > option however. JkOptions is probably fine for 1.2. Not sure where it
> > should be set in Jk2.
>
> Thanks. I'm not sure about mod_jk2 either. The latest reports show that
> the code still doesn't work.
Great to have it in jk 1.2.x.
BTW, what's the default behaviour ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs
commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2002-07-24 at 06:47, Bill Barker wrote:
> > 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
> >
>
> I can live with any but the first. It would be nice to have it as a config
> option however. JkOptions is probably fine for 1.2. Not sure where it
> should be set in Jk2.
Thanks. I'm not sure about mod_jk2 either. The latest reports show that
the code still doesn't work.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Posted by Bill Barker <wb...@wilshire.com>.
> 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
>
I can live with any but the first. It would be nice to have it as a config
option however. JkOptions is probably fine for 1.2. Not sure where it
should be set in Jk2.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>