How to Stream Audio/Video Files Such as Mp3, Mp4, Avi, etc Using a Servlet

How to stream audio/video files such as MP3, MP4, AVI, etc using a Servlet

A lot of media players require that the server supports the so-called HTTP range requests. I.e. it must be able to return specific parts of the media file on request with a Range header. For example, only the bytes at exactly the index 1000 until with 2000 on a file of 10MB long. This is mandatory for many media players in order to be able to skip a certain range of the media stream quickly enough and/or to improve buffering speed by creating multiple connections which each requests different parts of the file.

This is however a lot of additional code in your servlet which requires a well understanding of the HTTP Range specification. Usually the servletcontainer's (Tomcat, JBoss AS, Glassfish, etc) own default servlet already supports this out the box. So if there's a way to publish the media folder into the web by standard means, so that you don't need to homegrow a servlet for this, then I'd go on this route.

It's unclear which servletcontainer you're using, so I'll assume Tomcat in this example:

Just drop love.mp3 file in the public web content of the web project, so that it's just available by <a href="love.mp3"> without the need for a whole servlet.
Or, put the love.mp3 file in a new subfolder of Tomcat/webapps folder, e.g. Tomcat/webapps/media/love.mp3. This way it's available by <a href="/media/love.mp3">.
Or, put the love.mp3 file elsewhere on disk, e.g. /path/to/media/love.mp3 and add the /media folder as new context by adding the following line to Tomcat's /conf/server.xml:
```
 <Context docBase="/path/to/media" path="/media" />
```
This way it's available by <a href="/media/love.mp3"> as well.

Either way, Tomcat's own DefaultServlet, which has proper support for Range requests, will be used to stream the content.

But if there's absolutely no way to make use of servletcontainer's own default servlet, then you need to rewrite your servlet code in such way that it properly supports Range requests. You can get inspiration from open source examples such as Tomcat DefaultServlet and OmniFaces FileServlet.

Video Using HTML 5 and servlet

Honestly, this approach is absolutely not right.

You are sniffing the user agent in the server side and depending the business job on it. This is in all cases a bad idea. If all you want is to specify a different file depending on the user agent, then rather do it in the HTML side, with help of JavaScript or CSS. Both client side languages are able to identify the real browser without the need to sniff the user agent string (which is namely spoofable).
You are not responding correctly on Range requests. You're sending the complete file back instead of the requested Range. Firefox and IE do not use range requests and that's why it "works". Chrome and Safari use range requests.

This should be possible without sniffing the user agent and properly responding to Range requests by RandomAccessFile instead of File and byte[]. It's only pretty a lot of code to take all HTTP specification requirements into account, so here's just a link where you can find a concrete example of such a servlet: FileServlet supporting resume and caching.

However, much better is to delegate the job to the servletcontainer's default servlet. If it's for example Tomcat, then all you need to do is to add the following line to /conf/server.xml:

<Context docBase="D:\media" path="/media" />

This way the desired media files are just available by http://localhost:8080/media/final.ogg and http://localhost:8080/media/final.mp4 without the need to homegrow a servlet.

Simplest way to serve static data from outside the application server in a Java web application

I've seen some suggestions like having the image directory being a symbolic link pointing to a directory outside the web container, but will this approach work both on Windows and *nix environments?

If you adhere the *nix filesystem path rules (i.e. you use exclusively forward slashes as in /path/to/files), then it will work on Windows as well without the need to fiddle around with ugly File.separator string-concatenations. It would however only be scanned on the same working disk as from where this command is been invoked. So if Tomcat is for example installed on C: then the /path/to/files would actually point to C:\path\to\files.

If the files are all located outside the webapp, and you want to have Tomcat's DefaultServlet to handle them, then all you basically need to do in Tomcat is to add the following Context element to /conf/server.xml inside <Host> tag:

<Context docBase="/path/to/files" path="/files" />

This way they'll be accessible through http://example.com/files/.... For Tomcat-based servers such as JBoss EAP 6.x or older, the approach is basically the same, see also here. GlassFish/Payara configuration example can be found here and WildFly configuration example can be found here.

If you want to have control over reading/writing files yourself, then you need to create a Servlet for this which basically just gets an InputStream of the file in flavor of for example FileInputStream and writes it to the OutputStream of the HttpServletResponse.

On the response, you should set the Content-Type header so that the client knows which application to associate with the provided file. And, you should set the Content-Length header so that the client can calculate the download progress, otherwise it will be unknown. And, you should set the Content-Disposition header to attachment if you want a Save As dialog, otherwise the client will attempt to display it inline. Finally just write the file content to the response output stream.

Here's a basic example of such a servlet:

@WebServlet("/files/*")
public class FileServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException
    {
        String filename = URLDecoder.decode(request.getPathInfo().substring(1), "UTF-8");
        File file = new File("/path/to/files", filename);
        response.setHeader("Content-Type", getServletContext().getMimeType(filename));
        response.setHeader("Content-Length", String.valueOf(file.length()));
        response.setHeader("Content-Disposition", "inline; filename=\"" + file.getName() + "\"");
        Files.copy(file.toPath(), response.getOutputStream());
    }

}

When mapped on an url-pattern of for example /files/*, then you can call it by http://example.com/files/image.png. This way you can have more control over the requests than the DefaultServlet does, such as providing a default image (i.e. if (!file.exists()) file = new File("/path/to/files", "404.gif") or so). Also using the request.getPathInfo() is preferred above request.getParameter() because it is more SEO friendly and otherwise IE won't pick the correct filename during Save As.

You can reuse the same logic for serving files from database. Simply replace new FileInputStream() by ResultSet#getInputStream().

Hope this helps.

Download accelerator causes org.apache.catalina.connector.ClientAbortException: java.io.IOException when providing download from backing bean

Download accelerators (and media players!) expect files which are idempotently available via GET and HEAD requests (i.e. when just typing URL in browser's address bar) and preferably also support HTTP Range requests (so multiple HTTP connections could be opened to download parts simultaneously). The JSF backing bean method is only invoked on a POST request (i.e. when submitting a HTML form with method="post"). The ClientAbortException happens because the download accelerator didn't got the response it expected while sniffing for HEAD and Range support and aborted it.

If those files are static and thus not dynamic, then your best bet is to create a separate servlet which supports HEAD and preferably also HTTP Range requests.

Given that you clearly ripped off the source code from OmniFaces Faces#sendFile(), I'd suggest to rip off the source code of another OmniFaces artifact, the FileServlet. You can find snapshot showcase and source code link here: OmniFaces (2.2) FileServlet.

Here's how you could use it:

@WebServlet("/webinar_animation.mov")
public class YourFileServlet extends FileServlet {

    @Override
    protected File getFile(HttpServletRequest request) throws IllegalArgumentException {
        return new File("E:\\Animation\\IA\\Learning movies\\webinar1\\01_Aug_webinar_08\\Aug08_edited_webinar_animation.mov");
    }

}

<a href="#{request.contextPath}/webinar_animation.mov">Download file</a>

How to Stream Audio/Video Files Such as Mp3, Mp4, Avi, etc Using a Servlet