I wish someone could just check this matter. I can provide an XML file showing all ordered requests (with all params, responses, etc) with the dumb counter values showing up.
Thanks Xavier On Sep 4, 11:37 am, Reivax <xavier.yo...@gmail.com> wrote: > All requests are done authentified. > > Thanks > Xavier > > On Sep 4, 11:26 am, fbparis <fbou...@gmail.com> wrote: > > > According to the last api request you've done, X-RateLimit-Remaining > > can be user limit or IP limit (depends if you made an authentified > > request or not). > > > This can explain the X-RateLimit-Remaining values you've posted. > > > On Sep 4, 11:03 am, Reivax <xavier.yo...@gmail.com> wrote: > > > > I'm having this problem for a few days, and I've been monitoring ALL > > > requests sent to twitter, here is what I saw : > > > The value of the X-RateLimit-Remaining header is totally unreliable. > > > For instance, the response to a request will have it at 120, while the > > > next response will have it at 40. > > > Then subsequent request responses will have values such as 118, 39, > > > 37, 36, 117, ... and so on. > > > > All responses have the same X-RateLimit-Reset ! > > > > It all looks like there are 2 unsynchronized counters, and responses > > > get values from either one of them... > > > > The trouble is that one counter reaches 0 much too early, which makes > > > my twitter client says the maximum allowed request has been reached !! > > > > I make 3 requests every 2 minutes, so I should never reach the max. > > > > I have the exact same behavior when using the rate_limit_status > > > request. > > > > I made sure I have no other client on that account, and I can > > > reproduce the problem each time. Even if I had, there would not be > > > cases where it goes from 36 to 117 for 2 adjacent requests... > > > > Thanks for looking into that ! > > > (I can provide traces of the requests) > > > > Regards, > > > Xavier
