On 16/05/2010 21:15, Markus Mehrwald wrote: > Am 2010-05-16 21:11, schrieb André Warnier: >> Markus Mehrwald wrote: >>> I did not find the actual problem but I can live with this script not >>> delivered by apache. Maybe this is because the js is inside a jar file? >> >> I have to admit that in my previous analysis, this is a case which I did >> not envision. One learns every day. >> What makes you think that Apache httpd is smart enough to know that the >> js file is hidden inside of a jar file, and unpack it to get the file ?
Tomcat isn't. At a guess, myfaces is probably serving the file from the jar, as this horrible, horrible URL would seem to indicate: /faces/myFacesExtensionResource /org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader /12737082/popup.HtmlPopupRenderer/JSPopup.js (I added the line breaks, to improve readability) Which of HTTPD or Tomcat is returning the 404 for the request? Check both servers access logs to see where the URL appears with the 404 (or any other) status code & report back. If the request doesn't appear at all in Tomcat, then the mod_jk mapping isn't working as expected. p >> (Thank you for reminding me of some good pages of Evil Geniuses). > > That is the point. It is clear for me that the file could not be found > because it is in the jar but why do I get it in a different VirtualHost? >>> Another strange thing is the JkAutoAlias. It realy only works with the >>> appended ROOT directory. Otherwise the JkUnMount rule matches but >>> apache cannot find the according file. As long as I do only have one >>> application this is also OK for me. >> >> http://tomcat.apache.org/connectors-doc/reference/apache.html >> See: JkAutoAlias >> But don't miss this : >> Care should be taken to ensure that only static content is served via >> httpd as a result of using this directive. Any static content served by >> httpd will bypass any security constraints defined in the application's >> web.xml. >> >> Also, refer to the red warning on top of these directives. >> >> Apart from that, I think you should not use JkAutoAlias together with >> JkMount directives. Use one or the other. As far as I understand, >> JkAutoAlias is just a kind of "wildcard JkMount" anyway, with all the >> risks linked to that. >> >> I never use JkAutoAlias, so I am not sure that I really understand the >> details of what it does, but what I do not really understand in your >> configuration, is why you do >> JkMount /* worker1 >> AND >> JkAutoAlias /opt/tomcat/webapps/ROOT > > JkMount and JkAutoAlias are completely different. JkMount tells apache > to redirect all requests to Tomcat with /*. JkAutoAlias just maps the > given directory to apaches document space. The same thing should be > possible by using apaches Alias but JkAutoAlias takes care about the > META-INF and WEB-INF folder. > >> >> To me, basically, they do the same thing. Except that the second one is >> dangerous, because it might allow Apache to serve, for example, the >> contents of your /ROOT/WEB-INF/ directory. >> What happens if you try the URL >> http://yourserver/WEB-INF/web.xml >> See anything ? >> And what happens when you just take out that JkAutoAlias directive ? > > It causes a 404. I think as long as I do not JkUnMount /*.xml the > request will be passed to tomcat which will not deliver the content of > WEB-INF but you are right and I have to have a closer look at this. > >> >> >>> Now a third problem occured. I moved the JkMount/JkUnMount part out of >>> the virtual host into the global config. The mod_jk.conf is loaded >>> before any other file in conf.d (where ssl.conf resides). As far as I >>> know every virtual host should now uses this configuration but the one >>> for port 443 does not!? I have to put the same lines of the global >>> config into the virtual host for port 443. I am not sure but this also >>> might be a configuration problem of apache instead of mod_jk. >>> >>> >> That is how it is supposed to work. >> See: http://tomcat.apache.org/connectors-doc/reference/apache.html >> See JkMount : >> ... >> By default JkMount entries are not inherited from the global server to >> other VirtualHosts or between VirtualHosts. For the complete inheritance >> rules, see: JkMountCopy. > > But why does it work with the VirtualHost for port 80? > >> >> > I did not check the SetHandler part yet but shouldn't it also work >> with the JkMount's? >> It should, provided you read the JkMountCopy explanation. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
