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

Reply via email to