It's not just "many", it's all servlet engines. From the Servlet 2.5 spec:
"SRV.3.1.1: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of meth- ods on the request object. 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." These conditions essentially all apply (#1 - #3 trivially, security token parameter support largely implies #4). The question of what to do if the content type header is missing is interesting. But if the content is JSON, and the content-type is application/x-www-form-urlencoded, the request is wrong, and might be expected to fail on any platform. -- Adam On Tue, Mar 10, 2009 at 9:31 AM, Louis Ryan <[email protected]> wrote: > Its tricky in Java land because many servlet engines make the body > unavailable for form-encoded data. Given the prevalance of this platform its > probably worth a spec change. > > On Tue, Mar 10, 2009 at 4:41 AM, Chris Chabot <[email protected]> wrote: > >> That actually isn't spec compliant, is it? Since the spec states that the >> default should always be assumed to be 'json'. >> With php-shindig it checks to see if it has a recognizable content-type >> header, if not it checks for a recognizable format=foo query param, and >> otherwise sets the expected input & output formats to 'json', which means >> in >> this case everything works as expected. >> >> No biggy, and i have commit access to the php opensocial client library so >> I'll go and update that, however for people who roll their own (or use >> different libraries which makes the same assumption) it might be worth it >> to >> change this behavior in my opinion. >> >> -- Chris >> >> On Sun, Mar 8, 2009 at 5:09 PM, Adam Winer <[email protected]> wrote: >> >> > Your content type is >> > >> > Content-Type: application/x-www-form-urlencoded >> > >> > ... which is wrong, it's application/json. With the content type you >> > give, the form body gets parsed as query parameters, and isn't >> > available as JSON content. >> > >> > -- Adam Winer >> > >> > On Sat, Mar 7, 2009 at 11:52 PM, Chirag Shah <[email protected]> >> > wrote: >> > > I seem to be getting "Could not convert to class java.util.HashMap" >> when >> > > updating appData when the content-type is >> > > "application/x-www-form-urlencoded" on the latest 1.0.x-incubating >> build. >> > > >> > > I was able to track the issue down to line 99 of AppDataHandler where >> it >> > > internally tries to parse an empty postBody into a JSONObject and dies. >> > > Everything works fine if I change the Content-Type to application/json. >> > > >> > > What is the reccomended content-type when a client updates appData? The >> > > opensocial-php-client uses "Content-Type: >> > application/x-www-form-urlencoded" >> > > when it wants to update appData. >> > > >> > > >> > > Here's a dump of the request to my server (sandbox.orkut.com gives a >> > similar >> > > response): >> > > >> > > POST >> > > >> > >> /social/rest/appdata/@viewer/@self/147810927296?oauth_nonce=nonce&oauth_version=1.0&oauth_timestamp=timestamp&oauth_consumer_key=ck&xoauth_requestor_id=guid&oauth_signature_method=HMAC-SHA1&oauth_signature=signature >> > > HTTP/1.1^M >> > > User-Agent: osapi 1.0^M >> > > Host: snip^M >> > > Accept: */*^M >> > > Content-Length: 23^M >> > > *Content-Type: application/x-www-form-urlencoded^M >> > > ^M >> > > { >> > > "osapiFoo1":"newBar1"}* >> > > >> > > Here is the response: >> > > <u>The server encountered an internal error (Unknown error Could not >> > > convert to class java.util.HashMap) that prevented it from fulfilling >> > this >> > > request.</u> >> > > >> > >> >
