Failure to authenticate with /1.1/statuses/update.json but not /1/statuses/update.json

[meilleurerep]

hi,

I recently migrated by REST 1 code to 1.1. It seemed fairly trivial at the time but it seems that the 1.1-using code gets 401 statuses despite submiting the exact same request as the version-1 code (which gets 200 statuses).

So, I am sure that there is a bug in my code somewhere but I wonder if someone might have an idea of what I could possibly have screwed up when I replaced ‘1’ with ‘1.1’ in my url string.

[episod]

API v1.1 is stricter on two levels that can cause some issues for developers… the first is that it’s more strict with HTTP 1.1 compliance – it won’t tolerate unencoded reserved characters in query strings, URLs, or POST bodies. Further, the OAuth 1.0A implementation is also stricter, mainly because of the level of strictness required in HTTP. (For example, in API v1 perhaps a reserved character was allowed to be sent naked in the POST body and re-encoded only once for the OAuth 1.0a signature base string, but in API v1.1 the character would have to be encoded in the POST body for compliance, and as a result encoded again in the signature base string.

[meilleurerep]

Just to be clear since I do not speak oauth natively. You are refering to this encoding: http://oauth.net/core/1.0a/#rfc.section.5.1 ?

[episod]

That’s the right section for OAuth 1.0A (percent-encoding base strings via RFC-3986)

And for HTTP v1.1, it gets a little more complicated with different URL & body components (protocol, host, path, query string, etc) have some differing rules: http://www.ietf.org/rfc/rfc2396.txt

[meilleurerep]

thanks. digging into it!

[meilleurerep]

I was doing everything right. Just missing a proper Content-Type header (I had none and it worked magically before):

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Thanks for the hints: you did put me on the right track.