From: Mladen Turk [mailto:[EMAIL PROTECTED] > > Giampaolo Tomassoni wrote: > > > > Finally, it seems to me that mod_jk doesn't map a request to > tomcat as a sub-request, but instead seems to tweek the req->main > field, which may probably create the kind of problems reported in > BZ 36121. I'm not an expert of the apache req structure nor of > the mod_jk designs, but I have the "feeling" that it should go in > a sub-request instead. Am I wrong? > > This would also allow for a probably slower, but more complete > integration between Apache and Tomcat. In example, it would be > (probably?) possible to detect a 404 response from Tomcat to a > given DirectoryIndex name and attempt the next in list, if any. > Which in turn could allow a DirectoryIndex behaviour much more > uniform between the mod_jk and non-mod_jk cases. > > > > Better integration can be done by using mod_proxy_ajp that comes > with Apache 2.2. > 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? > Anything you mentioned can be done with ease using current > mod_jk and standard Apache directives, but the thing one > must always have in front, is the fact that Tomcat (or any > other backend) is part of virtual file system, not the > physical one used by Apache Httpd itself. Which would mean that this whole thread would be useless: apache would always work with an (empty) virtual file system, and every and each request it gets would just need to be forwarded to Tomcat. Easy. Too easy. > 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. > This is usually done by adding separate 'static' virtual directories > outside the application itself. Or maybe even inside 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... > Regards, > Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
