[Bug 54917] New: More relaxation on HttpServletRequest.getParts()

[bu...@apache.org]

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

[Bug 54917] More relaxation on HttpServletRequest.getParts()

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54917

Konstantin Kolinko <kn...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Konstantin Kolinko <kn...@gmail.com> ---
The use of "multipart/form-data" is defined by HTML specification (HTML 4.0
onwards). It was first specified by RFC2388.

Links:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2
http://www.w3.org/TR/html5/forms.html#multipart-form-data
http://tools.ietf.org/html/rfc2388

Regarding the description of @MultipartConfig (chapter 8.1.5 of Servlet 3.0
Rev.a), I think that 
a) maybe we could report it and ask it to be corrected as an editorial error
b) this wording is just in line with how the configuration option was named
simply "multipart config" and not "multipart form data config". (As to be open
for further wider use in the future or in different contexts).

It is just a configuration option. How this option is interpreted and used is
defined elsewhere: in chapter 3.2, as you correctly noted.

Thus I see no provision why Tomcat should ever try to process any other
multipart mime-type. (Unless one is about to follow "Zawinski's Law",
http://en.wikiquote.org/wiki/Jamie_Zawinski ).

I am closing this as WONTFIX.


> disagreeing implementations in Tomcat vs. GlassFish

What is so different in Glassfish?

> my current processing hack using JavaMail

Using an e-mail library to process an e-mail format is quite reasonable. Note
though that a) JavaMail is just a standard, an API. There exist different
independent implementations of it. b) There exist different libraries that can
parse mime formats.

If you start a thread on the users mailing list or elsewhere, maybe people can
come up with better options.

-- 
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

[Bug 54917] More relaxation on HttpServletRequest.getParts()

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54917

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The spec is quite clear that only multipart/form-data is supported.

Relaxing that requirement could be implemented as a container specific
extension to the spec.

Enhancement requests without patches or committer interest tend to languish in
Bugzilla for a few years before eventually being closed as WONTFIX.

-- 
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