tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: Discussion mod_jk and mod_dir interaction
Date Tue, 30 Jan 2007 13:33:00 GMT
Giampaolo Tomassoni wrote:
>> Any other 'better' integration would probably require patching
>> Apache core, and thats IMHO unfeasible by majority of users.
> Which one? Checking the 404 response? If mod_jk adopts sub-requests to Tomcat, why should
Apache get patched?
> Or if you mean the JkMount directive to be <Directory>-based, isn't it a matter
of how mod_jk handles its own directives? So, again, why would it need patching Apache?

Look, I don't wish to go into discussion with you, because
you obviously already have your perspective (IMHO wrong).

>> Static content delivery by Apache requires thorough application
>> design so that it can be served outside the application itself.
> No, it doesn't. The purpose of mod_jk is exactly this, I think.
> Company A makes a servlet-based application, which probably has both static and dynamic
content, using their preferred IDE/application builder. Company B publishes it using Tomcat
and Apache, and wants to avoid wasting cpu cicles and memory by allowing apache to delivery
the static content, not Tomcap.
> Mod_jk may be used just to map a virtual space to Tomcat. It is also used to deliver
static content more or less regardless of the servlet app. Of course, you may not be able
to deliver *all* the static content by apache (think, in example, to the deliverable resources
in Tomahawk), but most of your app's icons, css, js and the like can. An they get even cached
into the client this way.

What if the application is inside a .war or .sar. What then?
You don't have a file system, so if you wish to have a static content
served by Apache you *must* design your application accordingly.
First of all you will loose auto deployers, etc...

>> This both ease the configuration and increases the security,
>> because the worst thing you can do is to physically map the
>> web application to the Apache Directory. In that case all the
>> Tomcat and Servlet spec security is jeopardized.
> Well, not exactly. Of course you have to know what you're doing, but often it is not
that difficult: when you want to secure an area of a webapp, you often doesn't mean to secure
the delivery of its static contents (who cares of icons?). You mean to do this for the dynamic
> Sure, you have to avoid downloading "META-INF/*" and "WEB-INF/*". Well, in most cases
this is all you need to secure from the apache side.
> Also, if you need to secure some static branch of the VFS, you may just JkMount "/your_own_secure_statics/*"
and rely on Tomcat to handle it...

But all that requires management of two different configs.
Any change in Tomcat configuration (well, for start let's forget JMX,
an all other dynamic configs) would require to at least 'thinking' of
what that change would mean for the Apache Httpd in front, and that
simply sucks.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message