tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 54917] New: More relaxation on HttpServletRequest.getParts()
Date Wed, 01 May 2013 16:57:03 GMT
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.aarnio@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message