> Look, I don't wish to go into discussion with you, because > you obviously already have your perspective (IMHO wrong).
?!?! Well, of corse I have mine... > >> 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... Just unjar the war to the xxx.war directory and that's it. > >> 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 part. > > 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. Come on, it is not that complex. You got a webapp which, probably, uses one or two extensions for the dynamic content. Maybe it has also some directory-mapped servelet. Ok. Unjar it to a directory with the same name, protect "*-INF/*", JkMount the extensions used by dyn. content, JkMount the paths used by the extra servlets, maybe hide the extensions of files producing virtual dyn. content (like, in example, in jsf you often have .xhtml files which "map" to .jsf resources from the outside perspective) and it's done. You may even use JkOption ForwardDirectories to avoid mapping directory-mapped servlets... > Regards, > Mladen. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
