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]
