ironclaw hand wrote:
Ok thanks for the reply and the points are taken on board but as I said before
I havent actually done this before and I am initially trying to get it to work
as the existing system does (using the config files from the current
installation).
I know in an ideal world your suggestion would be best but I was just asked to
install current versions of apache, tomcat and mod_jk and get it all to work
and I was given some existing config files, as said I have never done this
before so initially I would actually like to get mod_jk working so that I can
actually see the java code getting executed and the dynamic content returned.
I dont think the overhead of tomcat serving static pages is the reason apache
is installed on these machines, I think it is because of the load balancing as
there are a number of machines with Tomcat installed on them that will be in
the load although initially I am only trying to get apache to direct to a
tomcat on local host.
I was looking for some help understanding why mod_jk doesnt work for me,
surely this cant be related to the security issues you mentioned?
Well, you are probably mistaken there.
With the current configuration, what is apparently attempted is, for some URLs, to have
Apache httpd /not/ forwarding them to Tomcat via mod_jk, and instead having Apache httpd
serving them directly, using a "back door" into Tomcat's webapps/sft/ directory.
This /is/ a security issue, because in this way, any security mechanism that may be in
place at the Tomcat level to avoid delivering the wrong content, are bypassed.
That is why, from a security point of view, it is strongly recommended not to allow Apache
to see, and serve the content of, directories whose content should be controlled by
Tomcat. Your Alias and <Directory> section at the Apache level do just that, so they
create a large potential security hole, which then someone tries to plug using other
instructions (which by the way look like they're wrong and/or incomplete).
But apart from the security issue, this scheme has further drawbacks :
- it makes things more confusing as to whom is serving what
- Tomcat "knows" that a .jsp file's content is not to be served as is. It knows that this
kind of file has to be "compiled" into a servlet, and that instead of delivering the
content of the .jsp file, it should run the resulting servlet, and serve its response.
Apache httpd has no idea about that. It sees a .jsp file as just a text file, and happily
serves its contents as is (even if the .jsp source file contained some information which a
user should never see).
And that is exactly what you are seeing.
Something in your present configuration allows Apache to "see" these jsp's, and serve them
directly. It is not very clear at the moment how this happens. In order to remove some
potential reasons why this could happen, Chris and I showed you how to modify your
configuration so that in the principle, it should not happen. Or at least, it should
remove one potential way in which it could be happening, leaving us with a more
transparent situation helping to find the real reason.
A useful tool to find out what happens is the mod_jk logfile. Increase JkLogLevel
gradually, until you see which URLs mod_jk is actually forwarding to Tomcat (and which
ones it is not, and why not).
A bit of background, to understand what happens :
When mod_jk is configured within Apache httpd, it acts as a "content generator". For
Apache httpd, it is mod_jk itself which creates the content that is returned to the user.
Apache httpd has no idea that behind mod_jk, there are one or more Tomcats who actually
do the work.
When it comes time to generate the response to a request URL, Apache passes this URL in
turn to all configured "content generators" (one of them being mod_jk). Each of these
content generators gets a shot at deciding whether it wants to generate content for that
URL, or just decline. If the content generator declines, Apache passes the URL through
the next content generator in the chain, to see if it does better. The last content
generator in the chain is the Apache builtin one, which reads the file from disk and sends
the content back "as is".
In other words, mod_jk gets to see /every/ request URL, and gets to decide if for this
one, it wants to pass it on to Tomcat or not. It decides this on the base of an internal
table it has built at server startup, on the base of the JkMount/JkUnmount instructions it
knows about. If it decides that this URL is not for Tomcat, it returns a "declined" answer
to Apache, and Apache proceeds to ask the next module. If mod_jk decides to pass this
request to Tomcat, then it does so using the AJP connection, and waits for Tomcat's
response. When it gets the Tomcat response, it returns it to Apache (as if it had created
it itself), along with a return code that means "here is the response, you do not need to
call any other module anymore".
What is most probably happening in your case is one of two cases :
- either this request never makes it to the VirtualHost in which this mod_jk is activated.
In that case, the mod_jk log would not even show the requests for these .jsp's.
As a result, Apache defaults to handling the request with its own content generator, which
just returns the .jsp file from disk.
- or the request makes it to the VirtualHost, and mod_jk sees it (and puts this in the
log), but mod_jk for some reason does not find a match with the request patterns that it
should forward to Tomcat. The log will show you that also.
As a result, Apache also defaults to handling the request with its own content generator,
which just returns the .jsp file from disk.
In both these cases, due to your present configuration, Apache /can/ deliver the .jsp file
"as is", because it can see them, directly in the Tomcat webapps/sft directory. If it
didn't, then you'd get a 404 error when you request a /sft/*.jsp URL.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
