Sometimes the rate_limit_status call is not returning a 302 to  
redirect, or the rate_limit_status xml, but HTML with a meta refresh  
in it (which curl doesnt understand to follow redirect/retry).

Its not huge problem for us, but it can affect some throttling code  
people may or may not be implementing. (when you get this response, a  
subsequent retry request usually succeeds 95% of the time)


Here is an example response I am talking about:

curl http://twitter.com/account/rate_limit_status.xml -L -v
* About to connect() to twitter.com port 80 (#0)
*   Trying 168.143.162.68... connected
* Connected to twitter.com (168.143.162.68) port 80 (#0)
 > GET /account/rate_limit_status.xml HTTP/1.1
 > User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2  
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8
 > Host: twitter.com
 > Accept: */*
 >
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Connection: Close
< Pragma: no-cache
< cache-control: no-cache
< Refresh: 0.1
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd 
">
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd";> -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="0.1">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<TITLE></TITLE>
</HEAD>
<BODY><P></BODY>
</HTML>



On Aug 8, 2009, at 11:20 AM, Chad Etzel wrote:

>
> Hmm,
>
> Unfortunately this 302 business will completely goof OAuth calls.
>
> If you are able to programmatically see that you are getting these
> redirects, try calling the account/rate_limit_status call [1] (it
> could be any call, but this one is "free" and is a GET). You should
> still get a 302 (I'm pretty sure). Then if you jump through the
> redirect hoops with this call, it should clear you from more 302's for
> a while.
>
> I'm out today, but if someone could try this and report back if it
> works that would be helpful.
>
> [1] 
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0rate_limit_status
>
> Thanks,
> -Chad
>
>
>
> On Sat, Aug 8, 2009 at 6:31 AM,
> timwhitlock<tim.whitl...@publicreative.com> wrote:
>>
>> I've seem the 302 Location headers having invalid URLs... i.e. two  
>> "?"
>> symbols.
>> The original query string and then an additional "?" for the token at
>> the end.
>> Following this redirect blindly has resulted in a Forbidden response.
>>
>> Also it is unclear whether the redirect location needs to be re-
>> signed? (I am not doing so, but may explain the 403?)
>>
>>
>>
>>
>>
>> On Aug 8, 8:14 am, Rich <rhyl...@gmail.com> wrote:
>>> Excellent our client now supports the 302's :)
>>>
>>> On Aug 8, 7:37 am, Chad Etzel <c...@twitter.com> wrote:
>>>
>>>> You may have to follow redirects more than once *wink wink nudge  
>>>> nudge*
>>>
>>>> with curl you can add --location flag. There's a good bit of info  
>>>> in
>>>> the man page as well.
>>>
>>>> If using curl with PHP, you can set:
>>>> curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);
>>>
>>>> HTH,
>>>> -Chad
>>>
>>>> On Sat, Aug 8, 2009 at 1:31 AM, TjL<luo...@gmail.com> wrote:
>>>
>>>>> All of my scripts check for "Status 200" before proceeding.
>>>
>>>>> Now we are (sometimes) getting a 302, but when I try
>>>
>>>>> curl --netrc -s -D -http://twitter.com/account/rate_limit_status.xml
>>>
>>>>> Gave me a 302 with a Location of:
>>>
>>>>> http://twitter.com/account/rate_limit_status.xml?c73f7db0
>>>
>>>>> but when I tried
>>>
>>>>> curl --netrc -s -D - 
>>>>> 'http://twitter.com/account/rate_limit_status.xml?c73f7db0'
>>>
>>>>> it seemed to want to redirect me to
>>>
>>>>> http://twitter.com/account/rate_limit_status.xml
>>>
>>>>> If "accepting 30x" is a requirement now, I'd like some advice on  
>>>>> how to do so.
>>>
>>>>> TjL
>>

Reply via email to