I'm not entirely sure what you are saying, however I wrote a
multipart/form-data parser whos contructor is passed req.getInputStream()
and it works fine under Tomcat. I use the service method
of the HttpServlet class rather than doPost, I don't think that would make
any difference.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 15, 2001 7:52 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: FLAW IN SERVLET SPECIFICATION IS THE REASON FOR LACK OF
STANDARD SUPPORT FOR FILE UPLOAD
Ufortunately both servlet spec 2.2 as well as the proposed servlet spec 2.3
are not compliant with
neither RFC 1867 nor RFC 2616 although in some parts of the specs mentions
is given of HTTP 1.1 and
one is let to believe that those specs be compliant with HTTP 1.1.
A further evidence which let believe that the spec 2.2 and 2.3 are fully
HTTP 1.1 compliant is the following statement
found in the introduction of the text:
The following Internet Specifications provide relevant information to
the development and
implementation of the Servlet API and engines which support the Servlet
API:
· RFC 1630 Uniform Resource Identifiers (URI)
· RFC 1738 Uniform Resource Locators (URL)
· RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
· RFC 1808 Relative Uniform Resource Locators
· RFC 1945 Hypertext Transfer Protocol (HTTP/1.0)
· RFC 2045 MIME Part One: Format of Internet Message Bodies
· RFC 2046 MIME Part Two: Media Types
· RFC 2047 MIME Part Three: Message Header Extensions for non-ASCII text
· RFC 2048 MIME Part Four: Registration Procedures
· RFC 2049 MIME Part Five: Conformance Criteria and Examples
· RFC 2109 HTTP State Management Mechanism
· RFC 2145 Use and Interpretation of HTTP Version Numbers
· RFC 2324 Hypertext Coffee Pot Control Protocol (HTCPCP/1.0)1
· RFC 2616 Hypertext Transfer Protocol (HTTP/1.1)
· RFC 2617 HTTP Authentication: Basic and Digest Authentication
As you certainly know, RFC 2616 relies upon RFC 1867 for FORM handling even
though RFC 1867 is still in "Experimental" status.
I strongly advice either to modify the servlet spec and make support for RFC
2616 and RFC 1867 complete,
or to write more clearly that this is not the case. Ideally, it would be
very useful if deviations of the spec from those RFC be described in
detail.
I stumbled across this problem when trying to submit a POST with
enctype="multipart-form/data" to Tomcat 3.1 and Tomcat 3.2.1
and got always nulls. Then I looked in the source and found that the
javax... returns NULL in case that the submitted POST contains
data but the content type not be= "application-xxx-www-form-urlencoded".
According to the specs,
"If any of the getParameter family of methods is not called, or not all
of the above
conditions are met, the post data must remain available for the servlet
to read via the
request’s input stream."
but unfortunately that is not the case since the javax.. implementation
returns null as result of the doPost with the enctype="multipart-form/data"
The only way to handle that problem (and still remain "pure Java") is
currently to extend the HttpServlet with a doPost which supports also
enctype="multipart-form/data" such as done by Jason in his classes
(http://www.servlets.com/resources/com.oreilly.servlet/index.html) however
one would normally expect such functionality to be provided by *any* servlet
implementation and for sure by the "servlet standard" !
As myself, several hundreds of other developers are hampered by this fact as
one can easily find by searching in the archives of the mailing
lists for example at technet.oracle.com in the XML discussion group, or in
tomcat mailing lists.
Your constructive comments will be appreciated.
Luca Toldo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
