Andre,
Thank you for the detailed response I can see now that the config was probably
never actually quite right...
I have amended the log level to debug and I now can see this in the mod_jk.log
file:
[Tue Apr 24 10:45:35.203 2012] [20188:3044006768] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/announcement.jsp
[Tue Apr 24 10:45:35.266 2012] [20287:2844699504] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/images/sft.css
[Tue Apr 24 10:45:35.269 2012] [20188:3033516912] [debug]
jk_map_to_storage::mod_jk.c (3773): missing uri map for
sfta.a.b.c:/sft/images/logo.gif
It looks like mod_jk is receiving from apache but it doesnt know what to do
with the request. Is this correct? I have been reading about this and people
have suggested in other forum posts to use:
JKMountCopy On - within the virtual host directive
I have tried this and it doesnt make any difference although I am assuming this
is because my JKMounts are actually defined within the virtual host and not
globally? If I run a tcpdump on port 8009 I never actually see any packets so
it never reaches tomcat again probably because of the missing uri map issue.
As a side note would you reccommend dropping mod_jk and using mod_proxy as some
posts suggest?
> Date: Tue, 24 Apr 2012 11:11:33 +0200
> From: a...@ice-sa.com
> To: users@tomcat.apache.org
> Subject: Re: Mod_jk returning source code of jsp files
>
> 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
>
