Matt is right on the money here. And if you are using .NET, you can avoid the challenge-response issue by setting your Authorization header directly, rather than creating a NetworkCredential instance. That's the only way to avoid the initial two hits to the API before a handshake is established.
request.Headers["Authorization"] = "your base64 encoded username:password here"; On Apr 30, 12:17 pm, Matt Sanford <[email protected]> wrote: > Hi there, > > The most common cause of X-RateLimit-Remaining not matching a > call to rate_limit_status is that you're not authenticated when > calling rate_limit_status but you are when making the call with the > different header. This is usually caused by libraries that require a > 401 response before they provide credentials, as is the case with .NET > unless configured otherwise. > > Thanks; > – Matt Sanford / @mzsanford > Twitter Dev > > On Apr 29, 2009, at 5:46 PM, moz wrote: > > > > > Hi. > > Is it only I that such a phenomenon occurs though remaining-hits of > > returning information seems not to be correct, and to differ from > > information that returns by the X-RateLimit-Remaining header about API > > of rate-limit-status? With this, I am embarrassed because it consumes > > API though there is a method of seeing the X-RateLimit-Remaining > > header > > when the method of limiting API is issued, too.
