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 ?
(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
