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

Reply via email to