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 m...@twitter.com 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.
