The configuration has been fixed. The configuration updates should be pushed out to all servers tomorrow morning PST.
On Thu, Nov 5, 2009 at 8:20 PM, Marcel Molina <mar...@twitter.com> wrote: > We've confirmed this and reported it to our operations team. We've > identified the problem and are actively fixing it. Thanks for the > detailed report. I'll let you know when the gzip compression is > restored. > > On Thu, Nov 5, 2009 at 7:19 PM, Jason Diller <jdil...@gmail.com> wrote: >> >> 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 >> > > > > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio