We're rolling back the Content-Type header correction on OAuth responses to text/html today - Deprecation Notice

[Taylor Singletary]

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!

Taylor
http://twitter.com/episod

[Taylor Singletary]

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:

[Taylor Singletary]

We'll be correcting this on Monday instead of today, folks.

Have a great weekend.

Taylor

On Friday, March 12, 2010, Taylor Singletary

--
Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod

[Taylor Singletary]

Hello Everyone,

This change is now officially rolled back. Let us know if you have
remaining issues surrounding this. We'll let everyone know when we're
closer to changing back to the more correct
application/x-www-form-urlencoded Content-Type.

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod