For our app, this started happening just after the DOS attacks and
have persisted since then. So my suspicion is that the 408 error is a
throttling mechanism. 408 is a connection read timeout. The problem as
I see it is that there is no way that the exception could get thrown
so fast if there were really a connection timeout. Is it possible that
twitter can customize the timeout for particular API callers?

With no code changes on our end, (our app is a server app in java that
uses the jtwitter libary) we see 408's and 200's. We haven't changed
the code at all and the behavior seems to be about 60% 408 responses
and 40% 200.

We weren't doing a very good job of giving our users a message that
would indicate it was a twitter API issue rather than our software so
I have begun updating to the latest version of Jtwitter which handles
the errors a lot more explicitly. However, when posting from my
sandbox instance, I ONLY get 403 errors (Forbidden). Perhaps this is
because the domain (localhost) doesn't match our API key?

At any rate, it isn't possible for us to provide a curl output since
we are posting via the jtwitter library so I don't know how to provide
anything useful as to debugging but this is awfully frustrating for
our customers. I'd love to know that there is a way to fix it on my
end by doing something different. It will be a pain (we'll have to
deploy code in order to make any changes) but it would help us satisfy
our own customers.

On Sep 6, 10:51 am, bosher <> wrote:
> Random 408 errors are being returned when users are attempting to
> "Sign in with Twitter" on my site
> Has anyone else been seeing this? Twitter, is there any way you can
> expand on the error message instead of just saying 408? That would
> help us better Understand & Report what's breaking...
> Thanks,
> Brett

Reply via email to