tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ironclaw hand <>
Subject RE: Mod_jk returning source code of jsp files
Date Tue, 24 Apr 2012 09:51:32 GMT


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:
> To:
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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,
> 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
> 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
> "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:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message