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-

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

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

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


On Mar 12, 7:28 am, Taylor Singletary <taylorsinglet...@twitter.com>
> 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

Reply via email to