-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Michael,
On 3/26/20 12:36, Michael Osipov wrote: > Am 2020-03-26 um 16:03 schrieb Christopher Schultz: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> All, >> >> 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 d. >> >> 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 RFC 7578 mentions item ordering but only stating that intermediaries may not reorder items. > * Browsers may order, read > https://html.spec.whatwg.org/multipage/forms.html#forms I wasn't able to find anything in there which requires (well...) item-ordering, but my testing with Firefox suggests that the order in the multipart request payload matches the document-order of the form. > * 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. My current code is looping through the parts and obtaining an InputStream from the large-parameter. After the loop, I read the InputStream fully. The previous "parts" are all being read during the loop (as simple String values). > * You must call delete, otherwise the temporary file will left on > disk Hmm. I haven't been calling delete() on any parts and I'm not seeing any files piling up anywhere, neither in Tomcat's "work" directory nor in the "tmpdir". I even tried a multi-GiB file. > I think your best bet is either: > http://commons.apache.org/proper/commons-fileupload/streaming.html > or https://james.apache.org/mime4j/ I've limited my uploads to 1MiB so I think I'd be okay if I had to buffer on-disk. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5+II4ACgkQHPApP6U8 pFgt5w//edoL5yrkt7kb4mTsZNviKwvXG7Pecvbd+sQX/cUEogXiW/siu6XpZ6Z+ MfjPrXU606mDHHwz95H9CxrNHz5VLOxquaCg5xZinIvfXGpqwlqtbMj/B/vY0344 un0z2sj5wVJEqF9MSXpQgYjdlFPZ29eHuOsffval34PyqVdCQf5Nxu3XwjggRW6K VTWzODxoccHcpHU7uDzL3vTiVfFMeRQQnqybgLl8jupTqwmpL29Aw4QvIvpX0HDg SN46Ovr9a3u8+oVzkSwaKJhyw1CzeT1KaXTdqg5qAEuugsTmnPA/VckReQcXEcvS GSioBNWZFg5p0Yv/PA9EGQxER28+N4rii2O/3H/CyEy48vxUuiizP/5fzufTGD+s kzewtYT7SRtACdVGIYZW9jcoYaQsYlYPTOQfYFH688MSAou2AaLSdiII/ZuLvSwz NipQ2kufsixVbHjtusyC6F3+XJWMEG3DwwaKaM5fo2AMucFd4u3gzA1pl16e/onF LbyXwUNJ7I3tlobQoMQYAw0BmHsQuIQxwLiL/B2L3QZSm9+yZ6qB3crkWJqjBVmH f0HpAr/pClBq7PFYwN2dvvOXr6yzoYkLAt8/Sq/TDR9SXA6vTZWaVXGyFBEWB5sa nQyXGDUq+GmfJgBF2k1PKNZx/PANwY7EajpyUj+8FeIVdfwc75E= =D89D -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
