How do you create "Aliases" in Apache Tomcat?

Question

I am working on a web application that allows users to upload attachments. These attachments are stored on a different drive than that of the web application. How can I create an alias (equivalent to Apache HTTP server's aliases) to this drive so that users can download these attachments?

Currently I am creating a context file and dumping it in CATALINA_HOME/conf/Catalina/localhost, but it gets randomly deleted every so often. The context file is named attachments.xml and the contents are shown below. I have also read about virtual hosts, but if I understand correctly, then a virtual host is not what I am looking for. I am using version 6.0.18 of Apache Tomcat.

attachments.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Context docBase    = "e:\uploads\attachments"
     reloadable = "true"
     crossContext   = "true">
</Context>

Answer 1

I spent a lot more time researching this and found a solution that solves the random deletion of the context files. I found this excerpt on Apache's website under the host configuration section:

You can nest one or more Context elements inside this Host element, each representing a different web application associated with this virtual host.

The virtual hosts are stored in the server.xml file located at *CATALINA_HOME\conf*. Tomcat comes configured with localhost as the default host. So, if we add the contents of attachments.xml from the first post, we get the following:

<Host name="localhost"  appBase="webapps"
    unpackWARs="true" autoDeploy="true"
    xmlValidation="false" xmlNamespaceAware="false">

    <Context path="/attachments"
             docBase="e:\uploads\attachments"
             reloadable="true"
             crossContext="true" />
</Host>

This is as close as one can get to defining aliases similar to Apache's HTTP server, I think.

Answer 2

There are multiple options.

1. Use Apache as frontend, delegating to tomcat by mod_jk or mod_proxy
2. Provide a download servlet in your own application, serving the requested file
3. Make the directory that you want tomcat to deliver a web application

each has some drawbacks and some advantages. I strongly prefer the first solution for multiple reasons:

• My main reasons apply to unixoid systems, which you are obviously not talking about: Only root can bind ports lower than 1024, e.g. 80. Therefor tomcat would need to run as root (I know that there are mechanics to allow users to bind to low ports, but I've never gotten to use them). Apache is usually started as root but drops these privileges as soon as port 80 is bound.
• Apache is said to be a lot better in serving static resources than tomcat (I've never measured it, but find it hard to believe the contrary)
• You obviously know how to create aliases in apache - it would be trivial to do so.

About the download servlet:

This way you'd have a servlet serving your static resources, which you might bind to the urls "/download/*" (e.g. in the application that also handles file uploads) You'd gain:

• You need to configure the directory where your files are stored only once
• If you need you might easily implement permission checks (e.g. login required for downloading)
• You need to deploy only one completely selfcontained application.
• The download servlet is trivial - find the file, set it's name and filetype in the output stream and stream it byte by byte, then close the output stream (be sure to handle attacking file names like "/download/../../../../etc/passwd" or "/download/C:/WINDOWS/someimportantfile.xxx"), e.g. by using the java.io.File constructor that gets the base directory as a separate parameter.

The third option has some severe drawbacks and opens you for attacks if you don't take special care of them:

• Tomcat does not serve directories, but webapps. Therefor "E:/upload/attachments" would need at least a directory named "WEB-INF", containing "web.xml". Take care to not provide write access to this directory and file from the uploading web application. With this provision you might let tomcat serve the directory.
• However: Configure the contained web.xml to not serve "*.jsp" as a jsp, otherwise tomcat would not just deliver jsp files but execute them. Imagine someone uploading "index.jsp" with <% System.exit(0); %> or more malicious content.

One additional thought: You don't need the extra crosscontext="true". This would imply that the webapplication that you deploy just to serve your files has access to other webapplications, e.g. is able to manage them or access their private data. Usually you don't need that at all, in the case of your question you definitely don't want that.