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.
-
Starting in version 2.0.0-M1, no FileUpload classes implement Serializable.
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 arbitrarily
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 behavior by setting the system property "org.apache.commons.fileupload.DiskFileItem.serializable"
to "true".
[top]
|
