tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OraPIM2...@aol.com
Subject FLAW IN SERVLET SPECIFICATION IS THE REASON FOR LACK OF STANDARD SUPPORT FOR FILE UPLOAD
Date Thu, 15 Feb 2001 02:52:16 GMT
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

Mime
View raw message