Thats pretty much where I am handling the 503, my client code intercepts the exception and then inspects the header. The other thing I noticed, and it is probably not best on this list is that you use WebRequest which raises a WebException, and you can't get the 503 out of it easily (at least from what I understand), where as HttpWebRequest raises HttpWebException which you can directly check for a 503 error.
Anyway, I really enjoy using Tweet# and if any .Net devs out there need a .Net Twitter library this is the one I recommend. Paul 2009/3/3 Dimebrain <[email protected]> > > Thanks for the feedback; right now you can get at the response in > instance.Root.Response (where instance is your FluentTwitter query), > which will give you the instance of the last response returned. I'll > look at this closer (unless you have a patch already of course). > > Daniel > > On Mar 3, 11:28 am, Paul Kinlan <[email protected]> wrote: > > Hi Daniel, > > > > I am using tweet# a lot, and it would be good if you catch the 503 error > > status on the rate limited requests (including the Retry-After header in > the > > response), I have had to implement it in tweet# for our product. > > > > Kind Regards, > > Paul > > > > 2009/3/3 Dimebrain <[email protected]> > > > > > > > > > I have experienced sending search requests out which return a plain > > > string, rather than JSON representing a twitter error. It's this: > > > > > "You have been rate limited. Enhance your calm." > > > > > a) What is the rate limiting based on, IP or client? What is the > > > limit? I develop a Twitter library (tweetsharp) and by default I send > > > the tweet# credentials along with the call. If this means that anyone > > > using my library will be rate limited because of that header > > > information, I need to know so I can force my users to provide their > > > own credentials so that the library isn't unusable in this area, and > > > > > b) Can we get his as XML, JSON and not a plain string? >
