I'll expand a bit on how you can prepare for this change.
The steps of the OAuth flow where you make a connection to Twitter's
OAuth endpoints to ask for request tokens or exchange a request tokens
for access tokens respond with query-parameter key/value pairs like
oauth_token and oauth_token_secret and sometimes other interesting
bits of miscellany. Responses (and requests!) that involve query
parameter key/value pairs have a Content-Type of application/x-www-
form-urlencoded.
Content-Types help HTTP clients interpret what's being sent to them.
If you hand me a rock but call it a poodle, I'm going to be pretty
confused. Right now, our Content-Type on OAuth responses is returning
a poodle, text/html -- but we're not sending you HTML. We're sending
you url-encoded query parameters.
If your client broke as a result of this change, look deeply at your
own code or any OAuth library or HTTP library that you use. Is there
anything conditional where you are explicitly looking for a text/html
response?
Some query parameter processing libraries automatically dereference
URL entities when processing. Maybe when you implementation was
receiving text/html responses it didn't de-reference the entities, and
so you wrote a routine to dereference them yourself. Now you're double
dereferencing or not dereferencing at all, and then you store your
request token or access token in a state that's different than you did
before and when you hand your tokens off to the Twitter API they are
malformed. That'd be bad.
We'll explore some options that will allow you to test this in
advance.
Look deeply at your code. Challenge assumptions you made based on
behavior that might not be to OAuth spec. This goes for everything
OAuth related. If you find something that we do that isn't to the
OAuth spec, let us know.
And while you're at it, don't forget to switch all your OAuth end
point URLs to using HTTPs: request_token, authorization, and
access_token.
Thanks!
Taylor
http://twitter.com/episod
On Mar 12, 7:28 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hello Developers,
Though it certainly would be more correct for us to properly set the
Content-Type HTTP header throughout the OAuth token acquisition
process to application/x-www-form-urlencoded, it has caused some
issues with a number of applications. This afternoon we will restore
the original behavior of setting the Content-Type header to text/
html.
Being in compliance with the OAuth specification is important to us.
Consider our old behavior now on deprecation notice. In four weeks or
so we'll begin setting the Content-Type header correctly again. We'll
announce a more formal deprecation date within a week of deployment.
We invite you to do the right thing with us.
Thanks!
Taylorhttp://twitter.com/episod
