> Give this site a try
>
> http://balusc.blogspot.com/2007/07/fileservlet.html
There's a fundamental problem with this, and it goes to (to me) the heart of a limitation with the Servlet spec.
At first glance, this fileservlet seems like it will do the trick. It's simple, it's straight forward, even has a "feature" for downloading the file.
The downside is that it completely ignores a large chunk of the HTTP protocol.
For example, it doesn't respond properly to HEAD requests. It doesn't handle If-Modified headers, it doesn't handle HTTP Chunking. And, specifically for this question, it doesn't handle ETags.
It WILL serve the file up, but that's really the most base lowest common denominator of functionality, and there's more to it than meets the eye.
I've always felt that there was a hole in the Servlet spec for not allowing developers to do something like "publish" a file name through the container. i.e. Here's an absolute path, please process this correctly for me Mr. Container for the consumer.
Instead we have to take a nominally simple process, and reinvent the wheel. If you look at the "DefaultServlet" which GF uses to serve static content, it's VASTLY more complicated than what most folks do. It handles the HTTP protocol more properly and, even more important, it leverages implementation specific performance aspects within the container to do the delivery more efficiently.
Unfortunately, the power of th DefaultServlet is not available to the generic Servlet API developer.
There are games that can be played to leverage the container but, they're just that -- games, and not portable.
There's no talk of this in the Servlet 3.0 spec, which I think is a shame.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=329287