Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Date: Thu, 15 Feb 2001 02:52:16 EST
From: OraPIM2000@aol.com
Subject: FLAW IN SERVLET SPECIFICATION IS THE REASON FOR LACK OF STANDARD
 SUPPORT FOR FILE UPLOAD
To: <servletapi-feedback@eng.sun.com>
Cc: <jhunter@servlets.com>, <smuench@us.oracle.com>,
        <tomcat-dev@jakarta.apache.org>, <tomcat-user@jakarta.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <d5.2613a3d.27bce4b1@aol.com>

Ufortunately both servlet spec 2.2 as well as the proposed servlet spec 2.3=20=
are not compliant with
neither RFC 1867  nor RFC 2616 although in some parts of the specs mentions=20=
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 HTT=
P 1.1 compliant is the following statement
found in the introduction of the text:

    The following Internet Specifications provide relevant information to th=
e development and
    implementation of the Servlet API and engines which support the Servlet=20=
API:
    =B7 RFC 1630 Uniform Resource Identifiers (URI)
    =B7 RFC 1738 Uniform Resource Locators (URL)
    =B7 RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
    =B7 RFC 1808 Relative Uniform Resource Locators
    =B7 RFC 1945 Hypertext Transfer Protocol (HTTP/1.0)
    =B7 RFC 2045 MIME Part One: Format of Internet Message Bodies
    =B7 RFC 2046 MIME Part Two: Media Types
    =B7 RFC 2047 MIME Part Three: Message Header Extensions for non-ASCII te=
xt
    =B7 RFC 2048 MIME Part Four: Registration Procedures
    =B7 RFC 2049 MIME Part Five: Conformance Criteria and Examples
    =B7 RFC 2109 HTTP State Management Mechanism
    =B7 RFC 2145 Use and Interpretation of HTTP Version Numbers
    =B7 RFC 2324 Hypertext Coffee Pot Control Protocol (HTCPCP/1.0)1
    =B7 RFC 2616 Hypertext Transfer Protocol (HTTP/1.1)
    =B7 RFC 2617 HTTP Authentication: Basic and Digest Authentication

As you certainly know, RFC 2616 relies upon RFC 1867 for FORM handling even=20=
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,=20
or to write more clearly that this is not the case. Ideally, it would be ver=
y 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=3D"=
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=3D "application-xxx-www-form-urlencoded". A=
ccording to the specs,=20

    "If any of the getParameter family of methods is not called, or not all=20=
of the above
    conditions are met, the post data must remain available for the servlet=20=
to read via the
    request&#8217;s input stream."

but unfortunately that is not the case since the javax.. implementation retu=
rns null as result of the doPost with the enctype=3D"multipart-form/data"

The only way to handle that problem (and still remain "pure Java") is curren=
tly to extend the HttpServlet with a doPost which supports also enctype=3D"m=
ultipart-form/data" such as done by Jason in his classes (http://www.servlet=
s.com/resources/com.oreilly.servlet/index.html) however one would normally e=
xpect such functionality to be provided by *any* servlet implementation and=20=
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 t=
omcat mailing lists.

Your constructive comments will be appreciated.

Luca Toldo