[408s] Random 408 errors having been appearing the last 48 hours

[bosher]

Random 408 errors are being returned when users are attempting to
"Sign in with Twitter" on my site TweetMeNews.com.

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
http://twitter.com/TweetMeNews/

[JEff]

We've been seeing 408's since the DOS attack back in July/August.

They feel like rate limiting on Twitter's part when overloaded.

Cannot tell since 408 isn't listed as an error they throw at
api.twitter.com

JEff

[fablau]

I am having the same issue, most of the times I cannot connect to
Twitter, I get 408 error and the API is mostly unusable form my side.
I am able to connect just a couple of times every 36-48 hours! Are we
the only people having this issue? How that can be possible? Is there
any way to contact Twitter folks about this issue? Are they aware of
this?

Any more thoughts and testimonials about this issue would be
appreciated.

Thank you for sharing.

Best,

[John Kalucki]

If you are having connection problems like this, please send your IP
address, account(s), a curl(1) -vvv trace, and a tcpdump of the
failure to a...@twitter.com.

-John Kalucki
http://twitter.com/jkalucki
Services, Twitter inc.

[rfisk]

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.

[Naveen A]

It might be useful if detailed (step by step) instructions of how to
generate the debug information twitter needs to track down this HTTP
data being returned on the API, I am not sure how much data you are
getting but I would really like to provide as much as I possibly can
and provide others with the tools to make providing this information
as easily as possible.

We unfortunately can't easily provide the necessary information as our
application runs on a mobile device where we can not easily get the
detailed information you require.

I understand how to provide the ip address, and the verbose curl
request.. Unclear what you are looking for when you are requesting a
tcp dump.. I would be happy to attempt to generate this information if
it will help expedite solving this problem..

On Sep 7, 10:06 pm, John Kalucki <jkalu...@gmail.com> wrote:
> If you are having connection problems like this, please send your IP
> address, account(s), a curl(1) -vvv trace, and a tcpdump of the
> failure to a...@twitter.com.
>

> -John Kaluckihttp://twitter.com/jkalucki

[John Kalucki]

Point your mobile device through a web proxy that you control. Monitor
the traffic there with tcpdump.

[Naveen A]

Thank John,
I wish it were that simple, it does not happen as often when the
request doesn't come from the Mobile Carriers servers.. Our client
actually makes use of direct to twitter connections (thorugh mobile
carrier) as well as proxied connections through our servers depending
on the action being taken. The HTML data issue plagues requests made
directly from the device but are much less frequent on requests we
proxy through our servers. Every time I try to reproduce on the
servers with curl and tcpdump, i have been unsuccessful in getting the
bad data to come back.

I apologize, I apparently put my initial response on the wrong thread,
as I am referring to the HTML META-REFRESH issues with 200 responses
that many have been seeing.

--Naveen Ayyagari

[Roy Hooper]

I'm still seeing this recurring problem. Are only oauth users
experiencing this? If so, maybe its time for us to give up on OAuth?

[Jeff Ayars]

We're using basic auth and having the problem so it's not OAuth related.

IP ranges, accounts, curl -vvv and TCP dump of failures sent to api@twitter yesterday. Seeing ~60% failures and 40% successes also. Haven't heard back from Twitter. Would love to hear something.

JEff

[Duane Roelands]

I'm having this issue as well, and also getting some 405s, which I
thought were long gone.

[H12山本 裕介]

Hi team,

Any update on this?
I filed a ticket for 408 code so that we can keep track of the issue
easily.
http://code.google.com/p/twitter-api/issues/detail?id=1036

Thanks,

[Raffi Krikorian]

hi!

we're actively working on this issue -- if you're personally experiencing this issue, it would be really helpful to get either a tcpdump of it occurring, or a curl -vvv simulating the issue.  in lieu of those, you can also send:

• date/time that the error occurred;
• what API endpoints were being requested;
• source IP address (along with any useful information on your network -- behind a NAT? proxy?)

feel free to send those directly to me.

thanks!

--

Raffi Krikorian

Twitter Platform Team

ra...@twitter.com | @raffi