Seems simple enough. As long as it doesn't break any tests I'll include it into the next release. If it does break tests we can expose via an optional method. Thanks for reporting.

Thanks for reporting this. I'll add a general safe_mode property that can augment various behaviors.

Not sure if this is needed for Twitter anyway, commenting out this line works perfectly fine for my (limited) calls to the Twitter API.
Or is there anything expected to break, and under what conditions?

The scenario is that Twitter has, in the past, resorted to doing 302 redirects when their under load. That's the only time when it will break if you don't have follow location set.

OK, good to know ... catching exceptions is always a good idea and indeed I got the plain old html fail whale page once in a while when testing the search API. The result would be useless anyway.

With the twitter api ... not catching exceptions isn't an option. I love it's simplicity but it's by far the most unstable api i've ever used :).

LOL - but then you missed the Foursquare api just before it's official release, those were fun times indeed!

Actually, I did not. I don't use foursquare but sam street asked me to help him port epioauth to foursquare...and I gave up after a couple days :).

Can you provide a code sample including the API you're hitting that doesn't populate the x-ratelimit-remaining header?

When using useAsynchronous(true), I must $arr = json_decode($response->responseText, true), otherwise I have no clue how to address individual elements. I mistakenly thought that your library handled this, unless of course I am further mistaken and it does. I've tried nesting another level of foreach loops, but your examples, IMHO, could use an example of accessing this deeper structure. There is no bug, per se, but I do use your documentation as a reference, and would like to see a little more on the "asynchronous" part, given the name and all. ;-)
P.S. Unless you want me to do it.

All useAsynchronous(true) does is that it blocks before returning. The return value you get is, otherwise, identical. responseText is always the raw response returned by the API (in this case json). response is the json_encoded version of responseText.

The library works in a manner where it blocks and populates the response only when you first try to access one of it's properties. As soon as you access any of it's properties (including code, response, and responseText) then it magically populates itself. Obviously this is all abstracted away (which can be good or bad).

As such, synchronous and asynchronous should be treated no differently. The interface exposed is identical (literally).

I still need to look into the problem of the headersb but let me know if this helps clarify or if you still have weird issues.

Could you include the code which isn't working?

When testing against the delete list API I received incorrect signature with POST using _delete. I haven't looked into why. Using delete() returns a 200 in the unit test. The list doesn't get deleted though. However, deleting a list via Twitter's website also appears broken. I thought the two might be related.

Thanks for reporting the bug...I'll get to properly testing DELETE next week.