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