Am 2020-03-26 um 16:03 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
I'm developing my first multipart handler since .. I dunno, maybe
2005? This is the first time I'll be using the Servlet 3.0 multipart
handling, of course through Tomcat. Some of these questions may have
answers which are "implementation-specific", so in this case, I would
like to know how things will behave in Tomcat specifically. Notes of
where the spec leaves things up to the implementation will be appreciate
I'd like to submit a form which has not only a large-ish file part,
but also some regular fields like <input type="text">. My
understanding is that I'll have to read those data by calling
Part.getInputStream(), wrapping the InputStream in an
InputStreamReader using the right charset, etc.
Do I get any help from any existing APIs for doing that, or do I have
to pull the Content-Type out of the Part-headers, look for a "charset"
parameter, etc., etc., in order to get the encoding and convert to a
String value? It seems like a pretty big hole in the multipart API not
to have something like that already available.
Can I rely on the client to send the fields in any particular order?
I'm not expecting to store the file on the server myself; I'd like to
process it in a "streaming" fashion and not touch the disk if
possible. I know that the server may store the file on the disk if it
decides to. I'm not terribly worried about that. I just don't want to
have to write the file to the disk TWICE, and I need information from
those other parameters in order to configure the stream-processing.
When iterating over the Collection<Part> returned from
HttpServletRequest.getParts(), am I required to process each part in
order immediately? Or can I store a reference to a Part for later?
This kind of goes along with the previous question.
When I'm done with a part, must I explicitly call Part.delete()?
A mere coincidence, we are currently designing an API around
multipart/related and I have investigated multipart requests deeply
after 10 years of abstinence.
W/o going to much in detail:
* Tomcat uses Commons File Upload w/ all its flaws and benefits
* Commons FU starts writing to disk as soon as it hits a threshold
* Don't expect an order unless specified by RFC 7578
* Browsers may order, read
* Streaming will be hard/impossible with Commons FU when not ordered. It
reads off the non-repeatable input stream which has to be segmented on
the fly into parts with headers and embedded payload. Consider that you
have payload beyond your huge payload. You simply cannot access it
unless you have consumed the huge one. In your case, if there are form
fields after the huge payload you need to decide how to process the huge
payload you *must* cache locally.
* You must call delete, otherwise the temporary file will left on disk
I think your best bet is either:
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org