Should use Content-Type: application/json when updating app data about opensocial-php-client

[GoogleCodeExporter]

I've added the application/json header to all outgoing requests, see:
http://code.google.com/p/opensocial-php-client/source/detail?r=87

Please do verify if the fix works for you and set the issue to 'Verified' if it 
did.

Thanks for the report!

Original comment by chabotc on 10 Mar 2009 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

I'm a confused as to how this will work. Inside io/osapiCurlProvider.php the 
only use
of $headers is

    if ($headers) {
      curl_setopt($ch, CURLOPT_HEADER, true);
    }

This won't actually set the headers. I think you might need to add a parameter 
to the
function, and explicitly set CURLOPT_HTTPHEADER.

    if ($httpRequestHeaders) {
      curl_setopt($ch, CURLOPT_HTTPHEADER, $httpRequestHeaders);
    }

Also the class io/osapiRestIO.php should stop signing the postBody now since the
content-type is nolonger www-form-urlencoded 
(http://oauth.net/core/1.0/#anchor14)

Thanks!
Chirag

Original comment by [email protected] on 10 Mar 2009 at 5:41

[GoogleCodeExporter]

http://code.google.com/p/opensocial-php-client/source/browse/trunk/src/osapi/io/
osapiCurlProvider.php
has been updated in svn to set the CURLOPT_HTTPHEADER with the $headers. 

The release however doesn't have this yet, once everything in regards to signing
settles we'll do another release update.

The OAuth signing is confusing me slightly at the moment. The OAuth spec says 
that
non-www-form-urlencoded requests shouldn't be signed, however Java based 
containers
can't calculate the OAuth signature of form-urlencoded POSTS (since it doesn't 
make
the POST body available then). So their solution is, I think, to *not* include 
the
body for the form-urlencoded POST's, but *do* include it for application/json
content-type posts.

So the code in svn currently reflects this thinking; However there is some 
discussion
on the oauth and opensocial spec lists on what the official way of doing this 
will
be, so there's no guarantee this will be final just yet.

Once the spec discussion has been settled, I'll update the code here right away 
too

Original comment by chabotc on 14 Mar 2009 at 9:48