https://issues.apache.org/bugzilla/show_bug.cgi?id=54917
Bug ID: 54917
Summary: More relaxation on HttpServletRequest.getParts()
Product: Tomcat 7
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
Assignee: dev@tomcat.apache.org
Reporter: matti.aar...@methics.fi
Classification: Unclassified
The wording at Servlet API 3.0 specification (and upcoming 3.1) carries
examples, and plain inconsistencies in it around the multipart request API.
This has resulted in disagreeing implementations in Tomcat vs. GlassFish.
The original MIME specification constructed the multipart/* as general
framework for delivering data attachments along with the primary contents.
There is also definition for few specific usages, like multipart/related, and
multipart/alternate.
Current ServletAPI 3.0 and preview of 3.1 are effectively stating around
chapter 3.2: "File Upload" that there shall be only support for
"multipart/form-data".
The description of @MultipartConfig (chapter 8.1.5) does speak of
"mime/multipart" which is not quite same thing as what chapter 3.2 speaks of,
nor exactly what MIME specification said -- better phrase there would be "MIME
multipart".
I use old protocols over HTTP that could use a bit more relaxed implementation
of what "multipart/" is in HttpServletRequest. My particular example is using
"multipart/related".
That specification wording of chapter 3.2 (maybe it was intended as an
example?) has resulted a strict compliance implementation at Tomcat 7, and this
very nice servlet request processing mechanism in there is practically useless
for me.
Really proper implementation (and specification) would support both "message/"
and "multipart/" structures allowing efficient iterative stream processing at
the servlet. And for that matter, also support encoding mode "chunked" in
parts, which my current processing hack using JavaMail does not support.
A bit hard thing there is that any Part can itself be a multipart message with
nested structure of its own, and request parsing needs to support that.
An iterator of Parts reading the input stream should be able to do it without
resorting to loading everything in memory, or using temporary files.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
