-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 6/17/2009 4:58 PM, André Warnier wrote: > Christopher Schultz wrote: >> >> Note that [restricted content-type] 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. " Right: this just says that when (properly-advertised) form data is present, it is available via the getParameter family of functions. > 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 ? It can't, nor should it. If the POST data is not properly-formatted form data, then it's left up to the servlet to decide what to do with it. > 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. Only form data is supported by the servlet API directly (via getParameter)... other types of data are supported indirectly through getInputStream/getReader. > 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. Note that multipart/form-data is not supported by the servlet API directly, either. If you want to read multipart/form-data, you need an 3rd-party library (or 1st party... if you feel like writing your own). > 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. getParameter, when called in the presence of POST data that is not formatted according to the spec's guidelines, does not consume any part of the request body. The servlet is free to read the data itself. No crashing is necessary. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5YGkACgkQ9CaO5/Lv0PBPygCfcBHwGH0O4z7ahSpkALGlcW3p 5PoAn2Xndch9aVPzUBM/xd0AV5sXDhBg =4bPs -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
