  ## FileUpload FAQ General Why is parseRequest() returning no items? Why am I getting "Read timed out" exceptions while parsing? Why is NoClassDefFoundError being thrown? Why does FileItem.getName() return the whole path, and not just the file name? FileUpload and Struts 1 I'm using FileUpload in an Action, but it's not working. Why? But I need to parse the request myself. How can I do that? FileUpload and Flash I'm using FileUpload to receive an upload from flash, but FileUpload will always throw an Exception "Stream ended unexpectedly". What can I do? FileUpload and Flash I have read, that there is a security problem in Commons FileUpload, because there is a class called DiskFileItem, which can be used for malicious attacks. ## General Why is parseRequest() returning no items? This most commonly happens when the request has already been parsed, or processed in some other way. Since the input stream has aleady been consumed by that earlier process, it is no longer available for parsing by Commons FileUpload. [top] Why am I getting "Read timed out" exceptions while parsing? The most common cause of these exceptions is when FileUpload is being used on a site that is using the Tomcat ISAPI redirector. There was a bug in earlier versions of that component that caused problems with multipart requests. The bug was fixed some time ago, so you probably just need to pick up a newer version. See the Tomcat bug report for full details. [top] Why is NoClassDefFoundError being thrown? There are two common causes for this error. Firstly, it might simply mean that you do not have the Commons IO jar in your classpath. FileUpload depends on IO (see dependencies) - you can tell if this is the case if the missing class is within the `org.apache.commons.io` package. Secondly this happens when attempting to rely on a shared copy of the Commons FileUpload jar file provided by your web container. The solution is to include the FileUpload jar file as part of your own web application, instead of relying on the container. The same may hold for FileUpload's IO dependency. [top] Why does FileItem.getName() return the whole path, and not just the file name? Internet Explorer provides the entire path to the uploaded file and not just the base file name. Since FileUpload provides exactly what was supplied by the client (browser), you may want to remove this path information in your application. You can do that using the following method from Commons IO (which you already have, since it is used by FileUpload).
          String fileName = item.getName();
          if (fileName != null) {
              filename = FilenameUtils.getName(filename);
          }
  [top] ## FileUpload and Struts 1 I'm using FileUpload in an Action, but it's not working. Why? Struts 1 recognises multipart requests, and parses them automatically, presenting the request parameters to your code in the same manner as if they were regular request parameters. Since Struts has already processed the request, and made it available in your form bean, the input stream is no longer available for parsing, so attempting to do so with FileUpload will fail. [top] But I need to parse the request myself. How can I do that? Struts 1 parses multipart a request as a part of the process of populating your form bean from that request. If, for some reason, you need to have full control over the multipart parsing, you can do so by configuring your action mapping without an associated form bean. (A better way of doing this, however, is to replace the default multipart handler with your own. See the Struts 1 documentation for details.) [top] ## FileUpload and Flash I'm using FileUpload to receive an upload from flash, but FileUpload will always throw an Exception "Stream ended unexpectedly". What can I do? At least as of version 8, Flash contains a known bug: The multipart stream it produces is broken, because the final boundary doesn't contain the suffix "--", which ought to indicate, that no more items are following. Consequently, FileUpload waits for the next item (which it doesn't get) and throws an exception. The problems details and a possible workaround are outlined in Bug 143 . The workaround suggests to use the streaming API and catch the exception. The resulting code could look like this:
      final List<FileItem> items = new ArrayList<FileItem>();

      HttpServletRequest servletRequest = [...];
      RequestContext ctx = new ServletRequestContext(servletRequest);

      FileItemFactory fileItemFactory = new DiskFileItemFactory();

      ServletFileUpload upload = new ServletFileUpload();
      FileItemIterator iter = upload.getItemIterator(ctx);
      try {
          while (iter.hasNext()) {
              FileItemStream item = iter.next();
              FileItem fileItem = fileItemFactory.createItem(item.getFieldName(),
                                                             item.getContentType(),
                                                             item.isFormField(),
                                                             item.getName());
              Streams.copy(item.openStream(), fileItem.getOutputStream(), true);
              items.add(fileItem);
          }
      } catch (MalformedStreamException e) {
          // Ignore this
      }
[top] ## FileUpload and Flash I have read, that there is a security problem in Commons FileUpload, because there is a class called DiskFileItem, which can be used for malicious attacks. It is true, that this class exists, and can be serialized/deserialized in FileUpload versions, up to, and including 1.3.2. It is also true, that a malicious attacker can abuse this possibility to create abitraryly located files (assuming the required permissions) with arbitrary contents, if he gets the opportunity to provide specially crafted data, which is being deserialized by a Java application, which has either of the above versions of Commons FileUpload in the classpath, and which puts no limitations on the classes being deserialized. That being said, we (the Apache Commons team) hold the view, that the actual problem is not the DiskFileItem class, but the "if" in the previous sentence. A Java application should carefully consider, which classes can be deserialized. A typical approach would be, for example, to provide a blacklist, or whitelist of packages, and/or classes, which may, or may not be deserialized. On the other hand, we acknowledge, that the likelyhood of application container vendors taking such a simple security measure is extremely low. So, in order to support the Commons Fileupload users, we have decided to choose a different approach: Beginning with 1.3.3, the class DiskFileItem is still implementing the interface java.io.Serializable. In other words, it still declares itself as serializable, and deserializable to the JVM. In practice, however, an attempt to deserialize an instance of DiskFileItem will trigger an Exception. In the unlikely case, that your application depends on the deserialization of DiskFileItems, you can revert to the previous behaviour by setting the system property "org.apache.commons.fileupload.disk.DiskFileItem.serializable" to "true". [top]