tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat 5.5 creates 0 byte files
Date Fri, 02 Jul 2010 14:27:08 GMT
Murat Birben wrote:
> Actually i'm not familiar with the interanls of
> enctype="multipart/form-data" thing. I think, i should read about this
> right?

Start here :
17.13 Form submission

Then graduate to this if you really want to know the details :
RFC 2045

But, as a summary :
With the form you showed earlier, what the browser will send to the server is a block of 
text data looking (approximately) like this :

POST /ResourceUploadServlet HTTP/1.1
Content-type: multipart/form-data; boundary=-----something----
.. more header lines, followed by one empty line ..

Content-type: text/plain
Content-disposition: form-data; name=FileName
Content-length: 18

Content-type: text/plain
Content-disposition: form-data; name=Path
Content-length: 10

Content-type: application/pdf
Content-disposition: form-data; name=Content; filename=some/path/and/file-name.pdf
Content-length: 132456
Content-transfer-encoding: Base64

.. and many similar lines

Each <input> of the <form> is going to result in one of the "form-data" blocks
above. The 
<input type="file"> will result in some very large block like the last one, which contains

the binary data of the file, encoded in Base64 encoding.

Tomcat 5.5 (and 6.0), natively, do not contain any standard code capable of parsing such a

POST data format and returning it nicely to your servlet.
(And you cannot just do a request.getParameter('Content') either.)
(but with Tomcat 7.0 however you should be able to).

To handle this kind of POST with Tomcat 5.5 or 6.0, you have either to do the work 
yourself (not recommended), or use something like FileUpload to do it.
But you cannot just read the body of the request, and copy it to a disk file.
Or rather, you can, but then you will have the whole block above in your disk file.

I do not remember how the FileUpload module really works, but it allows you to retrieve 
each of the blocks above (=form parameters) independently, and it will do all the decoding

for you.
For the file part (named "Content"), it probably gives you already a Stream, from which 
you can read to retrieve the (decoded) content of the file.
THAT is what you should be copying to a disk file.

Got the general idea ?

And, as pid was saying, the FileUpload documentation should certainly provide some good 

But, no matter how you do this,

<read this 3 times>
/NEVER/ accept the path or the filename that the user is entering in the form, to just 
write this file to disk.
</read this 3 times>

Remember what the user has entered, and write it somewhere as a text.  But create a path 
and a (unique) filename yourself, in your servlet, to write the file.
That will protect you not only against nasty people trying to crash your server, but also

against innocent users entering file names with spaces in them, or funny characters that 
are illegal in a filename on your system, or re-using a filename that already exists.
(to name just a few of the things that can happen).

All that still does not tell us why your servlet creates 0-size files, but maybe with the

above explanation you can figure this out yourself.

My scenario :
- your first getParameter() call "sucks in" the whole POST (all the above)
- your next getParameter() calls do not have anything else to get, and return null
- by the time you try to read the body of the POST, there is nothing left, so you also get

- and then you write this (null) to the output file, and you get a null-size file.

Repeat the above cycle once for each POST.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message