Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 6/17/2009 4:06 AM, André Warnier wrote:
Sorry to interrupt, but actually guys I believe that the problem is due
to the way the data is POSTed, which in this case is - I believe - invalid.
See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4
Note that this is an HTML thing, not an HTTP thing. HTML forms may only
be sent using two distinct Content-Types, but HTTP POST can do anything
it wants.
In a restricted sense, I agree.
But then, the servlet spec (2.5) explicitly talks about "form data" 2
times, for "post data" 1 single time.
"If the conditions are not met and the *post form data* is not included
in the parameter set, the *post data* must still be available to the
servlet via the request object’s input stream. If the conditions are
met, *post form data* will no longer be available for reading directly
from the request object’s input stream. "
Mmmm.
What does the 3.0 Servlet Spec say ?
Well, in section 3.1.1, it now only mentions "form data", twice.
My main objection though, derives from this previous paragraph, at the
end of section 3.1 :
"Data from the query string and the post body are aggregated into the
request parameter set. Query string data is presented before post body
data. For example, if a request is made with a query string of a=hello
and a post body of a=goodbye&a= world, the resulting parameter set would
be ordered a=(hello, goodbye, world)."
So, what in case there /are/ parameters in the URL ?
How would the servlet container /combine/ these with a body made of XML
or whatever else raw data ?
Maybe I am interpreting this one step too far, but it seems to me from
all this, that the designers of the Servlet Spec at least, were only
planning for form data, in pairs of parameter=value, and not for one big
data blob (without parameter name) in the body.
To me thus, the "correct" way - and the only way a browser would do it -
to POST this data, would be in the form of a multipart/form-data body,
itself composed of a MIME header and a body that would be the XML blob.
Basically, to me the whole point is that that HTTP server has to be
"prepared" to receive data in some predictable way. Out of the blue,
this webapp has no way to know that, for this request that comes in as a
POST, getParameters() would crash, because it is trying to get
parameter=value things where there are none. That seems wrong.
Any further expert comments here ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
