views:

897

answers:

2

I am trying to handle a file upload, and I'm using the com.oreilly.servlet.multipart.MultipartParser class to parse the posted data (in cos.jar). However, when I call the constructor for MultipartParser, I get this exception:

java.io.IOException: Corrupt form data: premature ending
    at com.oreilly.servlet.multipart.MultipartParser.<init>(MultipartParser.java:166)
    at com.oreilly.servlet.multipart.MultipartParser.<init>(MultipartParser.java:94)

Has anyone seen this before? From what I read, this means that the data ended before it found the boundary it was looking for. How can I fix this?

I am using cos.jar version 1.0.

Thanks!

+1  A: 

http://www.servlets.com/cos/faq.html

This indicates there was a problem parsing the POST request submitted by the client. There can be many causes for the problem:

  • The client hit the STOP button (not really a problem, but it does cause a premature ending)
  • A bug in the web form
  • A bug in the servlet
  • A bug in the web server
  • A bug in the browser
  • A bug in the com.oreilly.servlet library itself

History has shown the web server to be the most frequent cause of problems probably because there are so many different servers and few vendors appear to test their binary upload capability.

First, make sure your client isn't hitting the STOP button. Then, check if your problem is already posted on the "Servlet bugs you need to know about" resource on this site. If it's not well known, then you get to be among the first to learn about it! And you can share your discovery with us here!

Second, see if the upload works using the provided upload.html form and DemoRequestUploadServlet.java class. Some people have found bugs in their form that caused problems. Testing this combination will see if that's the case. One user, Duke Takle, found this exception was caused by a redirect: I was experiencing the same "premature ending" as Albert Smith. What I've found is that the problem was isolated to I.E. 5.0. The application that troubled me was doing a redirect after the construction of a MultipartRequest. It looks like this construction went well except on I.E. 5.0 the browser attempted to make the request again and by that time the ServletInputStream was empty. I've modified the application to simply write the needed response instead of redirecting. This problem was observed and fixed as described in Tomcat 4.0 and Weblogic 6.1. Other users have found bugs in their handling servlet where they call request.getParameter() instead of multipartRequest.getParameter(), and some servers falsely read the input stream when their getParameter() is called causing an "unexpected end of part".

Vladimir Dyuzhev
A: 

So, the problem was caused by me calling the MultipartParser constructor twice, by accident. It failed the second time, since the request had already been processed.

pkaeding