André Warnier wrote: > 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 > Having had to recently do some SOAP work, it looks to me that is at least partially what the OP was trying to begin with. SOAP performs a POST with XML as the body of the request. It's not URI encoded parameters or multipart data like the HTML Form posts, but a standard POST operation with an xml body. This is legitimate stuff to do and I would consider the spec broken if it didn't support it.
Just my two cents. --David --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
