Doug,

Thanks for your prompt reply.

Yes, it does sound like issue 795. I am sending a new, non-duplicate,
update. My app just ran into the rate limit again. I verified by
trying to post an update on twitter.com and got the message "Wow,
that's a lot of Twittering! You have reached your limit
of updates for the hour. Try again later."

While my account (@martins_test) was in this state, I sent this:

curl -u <username>:<password> -d "status=testing" 
http://twitter.com/statuses/update.xml
-D headerfile

The XML response contained the text of the last successful status
update. The HTTP headers started with

HTTP/1.1 200 OK

In other words, this is the same problem I ran into yesterday. Is
there any other data that would help troubleshoot this?

All the best,

/Martin



On Jul 13, 5:52 pm, Doug Williams <d...@twitter.com> wrote:
> Martin,
> This sounds like issue 795 [1].
>
> When you get the 200, are you sending the same (duplicate) text as the last
> successful update? If so, this is the expected behavior.
>
> However, if you are sending new (non duplicate) text and you are hitting the
> update limit, you should be receiving a HTTP 403 response code.
>
> Can you specify exactly what you are doing so we can debug?
>
> 1.http://code.google.com/p/twitter-api/issues/detail?id=795
>
> Thanks,
> Doug
>
>
>
> On Mon, Jul 13, 2009 at 4:38 PM, Martin Omander <moman...@google.com> wrote:
>
> > Hi there,
>
> > Earlier today I ran afoul of the rate limit for updates through the
> > API. But no error was returned to my app. To make sure my app wasn't
> > suppressing the error message, I sent an update using curl:
>
> > curl -u <username>:<password> -d "status=testing"
> >http://twitter.com/statuses/update.xml
> > -D headerfile
>
> > The status wasn't updated and no error message was returned. The
> > headerfile contained HTTP return code 200. But when I tried to enter
> > an update for the same account through the web interface at
> > twitter.com, I got an error message saying that I had posted too many
> > updates in the last hour.
>
> > When I used the curl command above and the update failed, I did notice
> > that the returned <text> element did not contain the status text I had
> > sent. Instead it contained my last successful update from 30 minutes
> > earlier. When there is a successful update, the <text> element seems
> > to contain the status update I just sent.
>
> > Should I examine the <text> element to verify that the update worked,
> > instead of checking for HTTP error codes? Or was this just a temporary
> > glitch today?
>
> > All the best,
>
> > /Martin

Reply via email to