On Thu, 26 Jun 2003, Henri Gomez wrote:

> Could we stop useless critics and flams and be more positives.

I'm sorry that you think it is useless to point out the specific areas
where mod_jk and mod_jk2 are doing things wrong.

> It's open source, and if you have objections, you're welcome to provide
> fixes.

To be honest, that isn't too appealing given the sad state of all
the different connectors available and the extremely poor state of
documentation about what is what and how things are supposed to
work.  But that is irrelevant, and doesn't change the validity of pointing
out what things are problems and why.

What is the release plan for mod_jk2?  Is there any plan for making it
production quality?  There doesn't seem to be much happening with it.
Is one better served to work on mod_jk instead and give up on mod_jk2?

> Never forget that mod_jk WAS DESIGNED to be cross web server compatible
> and that's why some of the Apache functions are not used.

mod_jk is the Apache specific module.  The fact that there are other
modules using some shared code that are specific to other webservers
doesn't change anything.

Web server specific plugins are the things that should tie tomcat in
with the way the particular webserver works.

It is quite sad to see how much worse webserver plugins have gotten
since the days of mod_jserv.

> BTW, on the Tomcat side, there is some URI checks since this problem
> could also appears when using the built-in http connector.
> In the actual case the problem seems to be that Apache handle the jsp
> directly since it didn't forward it to tomcat (probably because apache
> and tomcat run on the same machine)

The problem isn't that Apache doesn't forward it, the problem is that
mod_jk doesn't forward it because it reimplements things that Apache
can do for it a lot better and in a way that ensures it is compatible
with everything else happening in the webserver.  The same applies to
other webservers.  The mapping of what things should be passed to
tomcat and what things shouldn't is a security critical area that
can not be glossed over with a "ahh, we'll just make up our own way of
doing things since it means we don't have to bother with the webserver".
It is a plugin for the webserver, you have to bother with how the webserver

It was a bad design decision to take the shortcut of trying to embed
all the configuration within shared code and reuse it for every webserver.

By describing the problems, I'm hoping that someone who does have the
time right now can actually make one of the multitude of Apache --> tomcat
connectors into something production quality without gaping security,
performance, and stability issues.  If not, then it will have to wait
until I am at a point in my day job where we need to be deploying our
applications and they need to actually work right and I'll worry about
it then.

Oh, for whoever is trying to actually make mod_jk work right... you may
be able to do a "SetHandler jakarta-servlet" inside a Files section
in a Directory section, not sure if it supports it properly or not, although
that doesn't let you specify a specific worker.

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

Reply via email to