Interesting - I think this my problem - I keep getting invalid client
on windows using curl and fiddler2 - does this sound like these pieces
of software could uppercase the post variable names?
Rob
----
twitter: rsleggett
> --
> You received this message because you are subscribed to the Google Groups "SoundCloudAPI" group.
> To post to this group, send email to soundc...@googlegroups.com.
> To unsubscribe from this group, send email to soundcloudap...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/soundcloudapi?hl=en.
>
>
-Ullrich
I'll address the subject, as I can't speak to what the Apple libraries
do to URL data.
It seems there is some confusion between HTTP header fields, and
application/x-www-form-urlencoded key value pairs.
You are correct that the header key value pairs part of an HTTP 1.1
message (after the request line and before the body) should be handled
as case-insensitive. In our servers, we do treat these headers as
case-insensitive.
The curl example you gave does not add any headers (that's the -H
parameter), it only builds a URL encoded body for the POST you are
issuing. The documentation for the '-d' parameter in the curl man
page:
"
(HTTP) Sends the specified data in a POST request to the HTTP server,
in the same way that a browser does when a user has filled in an
HTML form and presses the submit button. This will cause curl to pass
the data to the server using the content-type
application/x-www-form-urlencoded.
...
Thus, using '-d name=daniel -d skill=lousy' would generate
a post chunk that looks like 'name=daniel&skill=lousy'.
"
So your two requests would look like this:
POST /oauth2/token HTTP/1.1
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8l zlib/1.2.3
Host: api.soundcloud.com
Accept: */*
Content-Length: 105
Content-Type: application/x-www-form-urlencoded
client_id=xxx&grant_type=authorization_code&client_secret=yyy&redirect_uri=appname://oauth-thing&code=zzz
Compared to:
POST /oauth2/token HTTP/1.1
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8l zlib/1.2.3
Host: api.soundcloud.com
Accept: */*
Content-Length: 105
Content-Type: application/x-www-form-urlencoded
Client_id=xxx&Grant_type=authorization_code&Client_secret=yyy&Redirect_uri=appname://oauth-thing&Code=zzz
The only fields that would qualify for case-insensitivity in rfc2616
would be "User-Agent, Host, Accept, Content-Length, Content-Type".
So we're really talking about making the query parameters to the OAuth
handshake case insensitive.
The OAuth2 spec isn't clear on whether or not the keys are expected to
be case-sensitive.
In the OAuth2 spec, there are some expected values that are explicitly
case-sensitive, so it's easy to infer that the keys are also assumed
to be case sensitive as they use the same characters in all examples.
I believe we are doing the right thing by assuming the keys to be
octets instead of character codes, and not accepting "Client_id" in
place of "client_id":
http://tools.ietf.org/html/draft-hammer-oauth2-00 Overall, case
sensitive keys reduces complexity. Imagine how to explain all the
possible expected behaviors in the case of receiving
"Client_id=123&client_id=456".
As Ulrich suggested - the best thing for debugging network clients to
do is crack open HTTP requests with Charles to find the difference
between requests and what is getting put on the wire.
http://www.charlesproxy.com Debugging data is usually gives the
fastest results.
Thanks for you suggestion, but we will stick with treating all
x-www-form-urlencoded keys as case-sensitive.
-Sean
On Mon, Feb 14, 2011 at 11:03 AM, RF <rfis...@gmail.com> wrote:
> curl https://api.soundcloud.com/oauth2/token -H 'client_id: xxx' \
> -H 'client_secret: yyy'\
> -H 'grant_type: authorization_code'\
> -H 'redirect_uri: appname://oauth-thing'\
> -H 'code: zzz' -d ""
>
> (empty -d to get a POST instead of a GET)
>
> And this doesn't work: {"error":"invalid_client"}, 401 Unauthorized.
>
> I guess my question has become "should this work?".
This will unfortunately not work.
When using these fields to authorize, they will need to be
x-www-form-urlencoded in the body or as query parameters in the URI as
described by:
http://tools.ietf.org/html/draft-hammer-oauth2-00#section-3.5.1
The OAuth2 spec does have a section for using HTTP headers for based
authorization:
http://tools.ietf.org/html/draft-hammer-oauth2-00#section-5.1
But this will only look for the authentication fields in the single
"Authorization" HTTP header.
As far as I can tell, there are no provisions in OAuth for getting a
token from passing the client_id and other URI parameters as HTTP
headers.
It sounds like it'd be convenient to treat the HTTP headers as URI
parameters for your tools, but I'm sure there are some other tools
that will help you construct urlencoded query strings too.
Happy hacking and I hope this explanation helps when using the SoundCloud API.
-Sean