API calls to http://twitter.com/ with Accept-Encoding:gzip in the headers are returning compressed data, while calls to http://api.twitter.com/1/ with the same headers do not.
You can demonstrate this with cUrl: curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" http://api.twitter.com/1/statuses/friends_timeline.json vs. curl --basic -u "user:pass" --header "Accept-Encoding:gzip, deflate" http://twitter.com/statuses/friends_timeline.json In the second example, you will get garbled response indicating that the data is compressed, whereas in the first you will get clear text. (Note: if you use --compress instead of --header then cUrl will decompress the response so you'll have to use Wireshark or some other network sniffer to see the raw data). We tracked this down because one of our users in Europe reported a big perf hit after we switched to the versioned endpoint. (see http://code.google.com/p/tweetsharp/issues/detail?id=104) I hope this isn't by design. Jason Diller Tweetsharp Contributor
