Update: This post is a crock. There is, in fact, a way to hide JSPs, and any other resource from the user’s browser: the WEB-INF directory. The 2.4 servlet spec (section SRV9.5) says:
The WEB-INF node is not part of the public document tree of the application. ... However, the contents of the WEB-INF directory structure… may be exposed using the
RequestDispatchercalls.
And that’s where I’ll be putting JSPs in future.
—Thanks to Joachim and Jason.
A Java servlet container is a web server, but it’s rare to see a Java servlet container directly attached to the Internet. Most often we deploy servlet containers behind ‘real’ web servers like Apache. Why is this?
The reason is JSPs. JSPs need to be placed into the servlet container’s URL space. However, typical java web applications are based on model two and break if a user points their browser directly at a JSP. If we could configure a servlet container so that a user couldn’t send HTTP requests to JSPs, that would be fine, but the servlet container spec doesn’t provide a way to do that. So we end up proxying our Java applications through Apache to give us control over the visible URL space.
Of course, you can use model one and make all your JSPs user callable, but Java system designers reject model one for all the same reasons they reject ASP and PHP.
In large deployments, using Apache brings advantages in security, manageability and efficiency, but in small deployments, its only benefit is to hide part of the URL space. I find this unnecessary complication galling.
All that said, the standard servlets-behind-Apache model is workable and sustainable in the long term, and so I am not advocating a complete revision of the servlet container specification.
What I am advocating is that future web framework developers avoid Sun’s mistakes: ensure that page templates aren’t placed into the public URL space; better still, ensure that page templates don’t directly respond to HTTP requests at all.