From users-return-233750-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Tue Apr 24 09:52:06 2012 Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EAFDF9127 for ; Tue, 24 Apr 2012 09:52:06 +0000 (UTC) Received: (qmail 58648 invoked by uid 500); 24 Apr 2012 09:52:03 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 58568 invoked by uid 500); 24 Apr 2012 09:52:01 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 58518 invoked by uid 99); 24 Apr 2012 09:52:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2012 09:52:00 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ironclawhand@hotmail.com designates 65.55.34.80 as permitted sender) Received: from [65.55.34.80] (HELO col0-omc2-s6.col0.hotmail.com) (65.55.34.80) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2012 09:51:52 +0000 Received: from COL113-W41 ([65.55.34.72]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 02:51:32 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_98f99427-7813-4822-b411-9fa4707356a0_" X-Originating-IP: [194.176.105.144] From: ironclaw hand To: Subject: RE: Mod_jk returning source code of jsp files Date: Tue, 24 Apr 2012 10:51:32 +0100 Importance: Normal In-Reply-To: <4F966E45.6040803@ice-sa.com> References: ,,, ,<4F956150.6050705@christopherschultz.net> ,<4F957500.7070801@ice-sa.com> ,<4F966E45.6040803@ice-sa.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2012 09:51:32.0168 (UTC) FILETIME=[D40E0C80:01CD21FF] X-Virus-Checked: Checked by ClamAV on apache.org --_98f99427-7813-4822-b411-9fa4707356a0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andre=2C Thank you for the detailed response I can see now that the config was proba= bly never actually quite right... I have amended the log level to debug and I now can see this in the mod_jk.= log file:=20 [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 peop= le 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 an= d not globally? If I run a tcpdump on port 8009 I never actually see any pa= ckets 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=2C 24 Apr 2012 11:11:33 +0200 > From: aw@ice-sa.com > To: users@tomcat.apache.org > Subject: Re: Mod_jk returning source code of jsp files >=20 > 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 cu= rrent installation). > >=20 > > I know in an ideal world your suggestion would be best but I was just a= sked to install current versions of apache=2C tomcat and mod_jk and get it = all to work and I was given some existing config files=2C as said I have ne= ver done this before so initially I would actually like to get mod_jk worki= ng so that I can actually see the java code getting executed and the dynami= c content returned. > >=20 > > I dont think the overhead of tomcat serving static pages is the reason = apache is installed on these machines=2C I think it is because of the load = balancing as there are a number of machines with Tomcat installed on them t= hat will be in the load although initially I am only trying to get apache t= o direct to a tomcat on local host. > >=20 > > I was looking for some help understanding why mod_jk doesnt work for m= e=2C surely this cant be related to the security issues you mentioned? > >=20 > Well=2C you are probably mistaken there. > With the current configuration=2C what is apparently attempted is=2C for = some URLs=2C to have=20 > Apache httpd /not/ forwarding them to Tomcat via mod_jk=2C and instead ha= ving Apache httpd=20 > serving them directly=2C using a "back door" into Tomcat's webapps/sft/ d= irectory. >=20 > This /is/ a security issue=2C because in this way=2C any security mechani= sm that may be in=20 > place at the Tomcat level to avoid delivering the wrong content=2C are by= passed. > That is why=2C from a security point of view=2C it is strongly recommende= d not to allow Apache=20 > to see=2C and serve the content of=2C directories whose content should be= controlled by=20 > Tomcat. Your Alias and section at the Apache level do just t= hat=2C so they=20 > create a large potential security hole=2C which then someone tries to plu= g using other=20 > instructions (which by the way look like they're wrong and/or incomplete)= . >=20 > But apart from the security issue=2C 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. I= t knows that this=20 > kind of file has to be "compiled" into a servlet=2C and that instead of d= elivering the=20 > content of the .jsp file=2C it should run the resulting servlet=2C and se= rve its response. > Apache httpd has no idea about that. It sees a .jsp file as just a text f= ile=2C and happily=20 > serves its contents as is (even if the .jsp source file contained some in= formation which a=20 > user should never see). > And that is exactly what you are seeing. >=20 > Something in your present configuration allows Apache to "see" these jsp'= s=2C and serve them=20 > directly. It is not very clear at the moment how this happens. In order= to remove some=20 > potential reasons why this could happen=2C Chris and I showed you how to = modify your=20 > configuration so that in the principle=2C it should not happen. Or at lea= st=2C it should=20 > remove one potential way in which it could be happening=2C leaving us wit= h a more=20 > transparent situation helping to find the real reason. >=20 > A useful tool to find out what happens is the mod_jk logfile. Increase J= kLogLevel=20 > gradually=2C until you see which URLs mod_jk is actually forwarding to To= mcat (and which=20 > ones it is not=2C and why not). >=20 > A bit of background=2C to understand what happens : > When mod_jk is configured within Apache httpd=2C it acts as a "content ge= nerator". For=20 > Apache httpd=2C it is mod_jk itself which creates the content that is ret= urned to the user.=20 > Apache httpd has no idea that behind mod_jk=2C there are one or more To= mcats who actually=20 > do the work. > When it comes time to generate the response to a request URL=2C Apache pa= sses this URL in=20 > turn to all configured "content generators" (one of them being mod_jk). = Each of these=20 > content generators gets a shot at deciding whether it wants to generate c= ontent for that=20 > URL=2C or just decline. If the content generator declines=2C Apache pass= es the URL through=20 > the next content generator in the chain=2C to see if it does better. The= last content=20 > generator in the chain is the Apache builtin one=2C which reads the file = from disk and sends=20 > the content back "as is". > In other words=2C mod_jk gets to see /every/ request URL=2C and gets to d= ecide if for this=20 > one=2C it wants to pass it on to Tomcat or not. It decides this on the b= ase of an internal=20 > table it has built at server startup=2C on the base of the JkMount/JkUnmo= unt instructions it=20 > knows about. If it decides that this URL is not for Tomcat=2C it returns = a "declined" answer=20 > to Apache=2C and Apache proceeds to ask the next module. If mod_jk decid= es to pass this=20 > request to Tomcat=2C then it does so using the AJP connection=2C and wait= s for Tomcat's=20 > response. When it gets the Tomcat response=2C it returns it to Apache (as= if it had created=20 > it itself)=2C along with a return code that means "here is the response= =2C you do not need to=20 > call any other module anymore". >=20 > 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.=20 > In that case=2C the mod_jk log would not even show the requests for the= se .jsp's. > As a result=2C Apache defaults to handling the request with its own conte= nt generator=2C which=20 > just returns the .jsp file from disk. > - or the request makes it to the VirtualHost=2C and mod_jk sees it (and p= uts this in the=20 > log)=2C but mod_jk for some reason does not find a match with the request= patterns that it=20 > should forward to Tomcat. The log will show you that also. > As a result=2C Apache also defaults to handling the request with its own = content generator=2C=20 > which just returns the .jsp file from disk. >=20 > In both these cases=2C due to your present configuration=2C Apache /can/ = deliver the .jsp file=20 > "as is"=2C because it can see them=2C directly in the Tomcat webapps/sft = directory. If it=20 > didn't=2C then you'd get a 404 error when you request a /sft/*.jsp URL. >=20 >=20 > --------------------------------------------------------------------- > To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org > For additional commands=2C e-mail: users-help@tomcat.apache.org >=20 = --_98f99427-7813-4822-b411-9fa4707356a0_--