Thank you very much for your earlier suggestions.  I actually started
to do similar changes on my code yesterday; and your suggestions
confirmed my planned design.  It would nice to have the official
changes on the trunk though.

Let me first clarify that for the scenario where using PUT with BODY,
OAuth parameters are almost never in the BODY of the request but can
be in the HEADER or QUERYSTRING, and only those updated fields, for
example, "status" are in the BODY.

In the case of MySpace, when trying to do status update using its API,
they do require PUT method, and with "status" information in the
body.  This API has only worked in the link here below however.  It
doesn't work with the current OAuth code; I'm not sure this is because
of limitation of MySpace support of this API.
http://developer.myspace.com/modules/apis/pages/oauthtool.aspx

Other services, such as Yammer and Brightkite, when trying to update
certain information, their APIs also require PUT method with updated
field parameter in the BODY of the request.

To answer your question, "Do PUT request bodies contain non-oauth
parameters that must be
signed?  That is, are parts of the request body included in the OAuth
signature base string? "

I think this may vary depends on the service. Again, I'm not sure if
MySpace uses this paradigm, but it seems to to the case from my
examination of their generated header.

Hi5 doesn't use OAuth, but they require similar signed request of
pretty much everything.

Hope this helps.  Thank you!

On Apr 1, 11:25 am, [email protected] wrote:
> Do PUT request bodies contain non-oauth parameters that must be
> signed?  That is, are parts of the request body included in the OAuth
> signature base string?
>
> On Mar 31, 10:54 pm, Brian Eaton <[email protected]> wrote:
>
> > I am familiar with the MySpace service provider, and I haven't seen it
> > require anything like putting oauth parameters in the request body.
> > ...
> > They do, like many other service providers, use PUT with request
> > bodies.  But in my experience they don't expect oauth parameters
> > there.
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to