[twitter-dev] Re: What is included In the "Queries are limited 140 URL encoded characters." restriction?
So the conclusion is: 1. DO NOT use the search operators that appear in the queries generated by the Twitter Advanced Search tool. For example, http://search.twitter.com/search?q=&ands= Do not use "ands" in your queries. The default interpretation of spaces in yr queries is logical AND. And these do count against query length. 2. The "query" is the q name/value pair. "?q=" (i.e. name q and proceeding "=") are not counted toward the 140 limit. Everything else up until the next parameter (delimited by "&") is counted toward the 140 character limited - including the search operators and their delimiters. Parameters (e.g. rpp), as these are separate name value pairs, are not part of the query thus not counted toward the max 140 character count. NOTE: There are exceptions and some overlap that may cause confusion. For example, Twitter defines "until:" as a search operator while you'll also see a "&until=" (i.e. "until" parameter) in the queries generated by the Advanced Search Tool. As a result, both "until:" and "&until=" are counted toward the 140 max character limit. The Twitter API is smart enough to see this overlap and recognize what you are going. However, it isn't documented. So you save you the trouble, if you are reading this, I'm noting this here. Leon On Oct 17, 9:52 pm, Scott Haneda wrote: > I brought that up the other day, "twitter eating their own dog food", > to which I was told they do, but only in some parts. It would be nice, > so that when the API is down, twitter is down, and we as developers > did not look like our apps suck, but that may not be a goal for > twitter, or it may be, I just do not know. I hope it is though. > -- > Scott * If you contact me off list replace talklists@ with scott@ *
[twitter-dev] Twitter API Wiki Lockdown
I was just wondering why the Twitter API wiki isn't open to edit? Well, I can understand that Twitter wants full control of it, but it seems like you could grow some really strong documentation using crowd- sourcing. Twitter would put out the bulk of the content, but indie developers could probably dot the i's and cross the t's. Also, the comments are turned off. If they were turned on you might get some good conversations going on the method pages. Kind of like the PHP documentation, ex: http://php.net/manual/en/function.count.php Then again maybe not. :) Just something I think about when I visit the wiki. Thought I'd finally comment on it. :)
[twitter-dev] Re: Draft of List API documentation
Sorry, that video is here: http://www.youtube.com/watch?v=NUVDP5sX2rA Copy/paste error.
[twitter-dev] Re: Draft of List API documentation
Once Twitter posted details of the API in this public forum, that opened the door to our discussing lists publicly (if it wasn’t open already). And I’ve been doing so. I even made a video showing TalkingPuffin all of Robert Scoble’s lists at once on a big screen: http://twitter.com/dcbriccetti/scala Simply enabling the Lists feature for many users and putting a little message on the Web page saying, “please don’t blog about it” is not a good approach. I’m not complaining, just explaining why I feel fine about talking about it. If I enter into an agreement with someone, I honor it, of course.
[twitter-dev] Re: Search API Rate limiting - App Engine (again)
Chad, Sorry for not being clear. I was thinking about Abraham William's suggestion above where Twitter Search API works with authenticated sessions+rate limiting, instead of IP based rate filtering. Just so you know, AppEngine has 30 second timeout on request to all AppEngine urls, and 10 second timeout on each individual HTTP request made within an AppEngine request. In case you are making multiple HTTP requests to Twitter within each individual AppEngine request, all the communication microseconds, from AppEngine to Proxy and Proxy to Twitter and then Twitter to Proxy and Proxy to AppEngine, quickly addup leading to timeouts. Personally i have tried quite a few scenarios to catch all the data i can, but from my experience, i can catch only 30%(sometimes better, sometimes almost nothing) of what i want, and rest just ends up with 503 and eventually since_id/max_id getting too old to get response from the Twitter Search API. So, right now Twitter is putting it's resources to offer a very robust Search API, but we as developers cannot use it effectively just 'cause of the way the hits are counted. Not to mention we are also investing funds to keep our apps running. Hope you understand our position. Thanks On Oct 18, 3:12 pm, Chad Etzel wrote: > On Sun, Oct 18, 2009 at 8:09 AM, vivekpuri wrote: > > > Will someone from Twitter please respond if there is an ETA to resolve > > this issue. Work arounds can never be really as effective as the real > > deal. > > Sorry, I thought it was clear from the previous email. There is no ETA > because it's not going to be resolved. GAE does not use an IP > infrastructure that is amicable to our rate-limiting logic, so if you > want to integrate IP rate-limited calls into your web-based > applications, you will need to either use the workaround stated > earlier or use a hosting service that will let you use a static IP. > > -Chad
[twitter-dev] Re: Draft of List API documentation
I created an app today using just the Lists API at http://listleagues.com when can I start publicising it? If anyone has any feedback let me know ol...@ollieparsley.com : thanks Ollie On Oct 16, 8:04 am, Marcel Molina wrote: > Hey folks. As some of you have likely read we're starting to do some > private beta testing of our new lists feature. We're not quite ready > to open it up to everyone but we've made some headway on the API and > wanted to share some details of what we've got so far. > > There are a handful of things on our todo lists so don't consider this > signed and sealed just yet. > > You may notice this API is a bit of a departure from the rest of the > API. It's a bit more, errr, REST than the rest. > > First off, here's the current payload for a list: > > > > 1416 > tall people > @noradio/tall-people > tall-people > 0 > 3 > /noradio/tall-people > public > > 3191321 > Marcel Molina > noradio > San Francisco, CA > Engineer at Twitter on the @twitterapi team, obsessed > with rock climbing & running. In a past life I was a member of the > Rails Core team. > > http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no... > http://project.ioni.st > false > 40059 > 9AE4E8 > 33 > 0084B4 > DDFFCC > BDDCAD > 354 > Mon Apr 02 07:47:28+ 2007 > 131 > -28800 > Pacific Time (US & Canada) > > http://a1.twimg.com/profile_background_images/18156348/jessica_tiled > true > 3472 > false > true > false > false > > > > === Lists === > > POST '/:user/lists.:format' > Creates a new list for the authenticated user. > > Parameters: > * name: the name of the list. (required) > * mode: whether your list is public of private. Values can be > 'public' or 'private'. Public by default if not specified. (optional) > > Usage notes: > ":user" in the url should be the screen name of the user making the > request to create the list > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORD -d "name=tall > people&mode=private"http://twitter.com/noradio/lists.xml > > POST/PUT '/:user/lists/:list_slug.:format' > Updates the specified list. > > Takes the same parameters as the create resource at POST > '/:user/lists.:format' (:name and :mode). > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORD -d > "name=giants&mode=public"http://twitter.com/noradio/lists/tall-people.xml > > GET '/:user/lists.:format' > Lists your lists. > > Supported format: > xml, json > > e.g. > curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml > > GET '/:user/lists/memberships.:format' > List the lists the specified user has been added to. > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml > > DELETE '/:user/lists/:list_slug.:format' > Delete the specified list owned by the authenticated user. > > Parameters: > * list_slug: the slug of the list you want to delete. (required) > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORD -X > DELETEhttp://twitter.com/noradio/lists/tall-people.xml > > GET '/:users/lists/:list_slug/statuses.:format' > Show tweet timeline for members of the specified list. > > Parameters: > * list_slug: the slug of the list you want the member tweet timeline > of. (required) > * next/previous_cursor: used to "page" through results (optional) > > Supported formats: > xml, json > > e.g. > curl -u > USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml > > GET '/:users/lists/:list_slug.:format' > Show a specific list you can use the new resource. > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people.xml > > === List members === > > POST '/:user/:list_slug/members.:format' > Add a member to a list. > > Parameters: > * id: the id of the user you want to add as a member to the list. (required) > > Usage notes: > The :list_slug portion of the request path should be the slug of the > list you want to add a member to. > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORD -d > "id=123456789"http://http://twitter.com/noradio/tall-people/members.xml > > GET '/:user/:list_slug/members.:format' > Members of the specified list. > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/tall-people/members.xml > > DELETE '/:user/:list_slug/members.:format' > Remove a member from the specified list. > > Parameters: > * id: the id of the user you want to remove as a member from the > list. (required) > > Usage notes: > The :list_id portion of the request path should be the slug of the > list you want to add a member to. > > Supported formats: > xml, json > > e.g. > curl -u USERNAME:PASSWORD -X DELETE -d > "id=123456789"http://twitter.com/noradio/tall-people/members.xml > > GET '/:user/:list_slug/members/:id.:f
[twitter-dev] Re: C# + OAuth + account/update_profile_image = 500 Internal Server Error
Simon, I believe the body of your post might be incorrect. It should look like this: POST /account/update_profile_image.xml HTTP/1.1 Content-Type: multipart/form-data; boundary=8cbed79c91b24f3 Host: twitter.com Content-Length: 3863(this will probably change now..) --8cbed79c91b24f3 Content-Disposition: form-data; name="image"; filename="test.jpg" Content-Type: image/jpeg (there's a few K of binary data here, the contents of the file) --8cbed79c91b24f3 The rest of the OAuth variables should be passed on the query string. I hope this helps. Cheers, Nicholas --- Nicholas Granado email: ngran...@gmail.com twitter: heatxsink web:http://nickgranado.com On Sun, Oct 18, 2009 at 2:42 PM, Zaudio wrote: > > Hi David, > > I found your excellent post hoping that it would solve the same > challenge for my app: updating profile image via Oauth... using > similar .net base to yourself... > BUT I just get the 401 all the time... despite taking your advice to > just sign with the HTTPmethod & URL My post data is laid out much > like yours... though I never got that 500 error... > > I've tried all sorts... dropping the & off the end different > encodings... > > What encoding did you use to encode your image, and then to post the > request? > > Does it still work for you... or did this get broken when Twitter > 'fixed' their Oauth implementation? > > Can anyone else advise if they have got this working and where I might > be going wrong? > > Thanks > > Simon (Zaudio) > > > > On Aug 19, 11:40 pm, David Carson wrote: > > Got this sorted out and working, and thought I should share the two > > pitfalls which were causing me problems. > > > > First of all, unbelievably, the 500 Internal Server Error was being > > caused by an extra carriage return between my last HTTP header and the > > first multipart boundary. Seriously. I had two blank lines in there > > instead of one. Removed the extra carriage return, and my 500 > > vanished, being replaced by a more reasonable "(401) Unauthorized - > > Incorrect signature" error. > > > > Secondly, the OAuth documentation seems a bit shaky when it comes to > > multipart/form-data POSTs. But basically, you do NOT use any of the > > POST parameters when creating your signature. And this includes all of > > the OAuth-specific parameters like oauth_consumer_key, > > oauth_signature_method, etc. Bit of a security hole imho, OAuth > > implements all this complexity to avoid man-in-the-middle or replay > > attacks, and as soon as you do a multipart POST it's all negated. > > > > So, my signature base was literally: > > > > POST&http%3A%2F%2Ftwitter.com%2Faccount%2Fupdate_profile_image.xml& > > > > Just the HTTP method and the URL. No parameters. > > > > Once I made that change to the signature generation, my request went > > through fine and my avatar changed. > > > > Hope this helps someone! > > > > Cheers, > > David... >
[twitter-dev] Re: Bug? Updates > 140 characters return success with prior update payload
I agree. A silent failure seems like the wrong behavior.. It should return an error if the tweet has failed to post. Also this change was made without any announcement that I recall seeing or can find now. This is a pretty significant change in behavior for existing clients.. We are failing to post because people are not getting an error and they believe it is our problem. Because the failure is silent we do not notify the user of the problem. We will update our code with a work around, but I would have expected some sort of announcement that this was going to happen. On Oct 17, 6:23 pm, Dave Sherohman wrote: > > On Sat, Oct 17, 2009 at 10:41 AM, Marc Mims wrote: > > > Updates longer than140characters should be forcibly truncated > > > according to the documentation. Instead, the update call returns with > > > a 200 status and the payload contains the prior update. > > > > Has there been achangeto the API or is this a bug. > On Sat, Oct 17, 2009 at 05:15:42PM -0500, Josh Roesslein wrote: > > This is achangein the API confirmed by one of twitter's API members. > > The docs should be updated soon. > > In that case, is there anychange(planned or current) which will > indicate when this has happened, or if the update has been rejected for > any other reason? Failing silently does not seem appropriate, > particularly when the failure returns the user's previous status. > > -- > Dave Sherohman
[twitter-dev] Re: C# + OAuth + account/update_profile_image = 500 Internal Server Error
Hi David, I found your excellent post hoping that it would solve the same challenge for my app: updating profile image via Oauth... using similar .net base to yourself... BUT I just get the 401 all the time... despite taking your advice to just sign with the HTTPmethod & URL My post data is laid out much like yours... though I never got that 500 error... I've tried all sorts... dropping the & off the end different encodings... What encoding did you use to encode your image, and then to post the request? Does it still work for you... or did this get broken when Twitter 'fixed' their Oauth implementation? Can anyone else advise if they have got this working and where I might be going wrong? Thanks Simon (Zaudio) On Aug 19, 11:40 pm, David Carson wrote: > Got this sorted out and working, and thought I should share the two > pitfalls which were causing me problems. > > First of all, unbelievably, the 500 Internal Server Error was being > caused by an extra carriage return between my last HTTP header and the > first multipart boundary. Seriously. I had two blank lines in there > instead of one. Removed the extra carriage return, and my 500 > vanished, being replaced by a more reasonable "(401) Unauthorized - > Incorrect signature" error. > > Secondly, the OAuth documentation seems a bit shaky when it comes to > multipart/form-data POSTs. But basically, you do NOT use any of the > POST parameters when creating your signature. And this includes all of > the OAuth-specific parameters like oauth_consumer_key, > oauth_signature_method, etc. Bit of a security hole imho, OAuth > implements all this complexity to avoid man-in-the-middle or replay > attacks, and as soon as you do a multipart POST it's all negated. > > So, my signature base was literally: > > POST&http%3A%2F%2Ftwitter.com%2Faccount%2Fupdate_profile_image.xml& > > Just the HTTP method and the URL. No parameters. > > Once I made that change to the signature generation, my request went > through fine and my avatar changed. > > Hope this helps someone! > > Cheers, > David...
[twitter-dev] Re: Why have you removed the HTML/CSS badge/widget?
http://twitter.com/widgets/which_widget click on html widget, and chose the one you want, it will help you build one. They are all html, though use Javascript to pretty them up. http://twitter.com/goodies/widgets That link does not as far as I can tell, for the Web site widgets, make flash widgets. I suspect you are confusing html widgets for flash widgets, just because Javascript is able to make them look more like what flash often appears. I just made this one http://dl.getdropbox.com/u/340087/Drops/10.18.09/widget-b51545b8-142935.png which is not flash, all html. You are probably getting pretty close to moving into an area of asking questions on a mailing list that was not designed to answer your questions. I suggest if you really do not like this, that you take it up with twitter support by opening a ticket. Hope that helps -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 18, 2009, at 3:55 AM, Jonathan Timar wrote: Yes, that is the one I mean. Well I am on the developer website because I found it through Google. And while I certainly know my way around HTML and CSS, any kind of programming is beyond the scope of my brain, so no I could not make my own widget without a lot of help. My widget didnt stop working, I just find it baffling that Twitter would remove access to a text/css widget on their website (and by access I mean remove all internal links and mention of it), and instead provide only bloated, impossible to truly customize flash widgets, especially given the minimalist nature of the Twitter service. On Oct 17, 11:24 pm, Scott Haneda wrote: Not sure I understand, you mean like this one:http://twitter.com/widgets/html_widget Either way, text only widget, you being on a developer mailing list, I am sure in all honestly, a few lines, maybe 10 lines or so, and you could have a widget to your liking. Whatever old widget your refer to, has to be in use by others, they could not just take it away, as that would break everyones sites who included it in their website. I suspect they may have moved it elsewhere, but I am certain the old widget still works. There are also 10's of websites that have twitter widgets, from simple to complex. Did your widgets stop working? If not, just copy the source from those and keep using them, they will continue to work. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 17, 2009, at 10:13 PM, Jonathan Timar wrote: I am referring to the text only version of this:http://twitter.com/widgets/which_widget , which is oddly still present on the Twitter website (I found it after some in depth Googling) but no longer linked to or referenced in any way, in favour of this page:http://twitter.com/goodieswhich features some far less useful and customizable widgets. What is the reasoning behind this? Does Twitter really think that there is no demand for a simply, fully CSS styleable widget?
[twitter-dev] Private lists showing up on memberships page
I've seen a couple instances now (@beaker and @mediaphyter) where a private list shows up on the list of a user's memberships. It doesn't seem like the existence of these private lists should be showing up in the memberships list, nor can I reproduce the issue on my own account. As an example, here's a brief snippet from http://twitter.com/Beaker/lists/memberships.xml (sidenote that the member_count shows up as 5 on the HTML version of the memberships page). 19351 Security @twowheelgeek/security security 0 0 /twowheelgeek/security private dpc
[twitter-dev] Re: Laying the foundation for API versioning
The change has been made but it probably hasn't been pushed out yet to the full cluster. I'll follow up with ops on Monday. Thanks. On Sun, Oct 18, 2009 at 1:10 PM, Dave Briccetti wrote: > > Thanks, but still failing today. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Problems Connecting to the API
Ryan, These 502s happen in my high-volume processes. I can't manually reproduce them. Most calls don't 502 after the second geometric back-off. I'm guessing it's just everyone doing a 9-hour catch-up against the API. Dewald On Oct 18, 4:54 pm, Ryan Sarver wrote: > Dewald, > > Can you produce some TCP dumps and requests with headers so we can better > debug? > > Thanks, Ryan > > On Sun, Oct 18, 2009 at 12:05 PM, Dewald Pretorius wrote: > > > I'm seeing lots of 502's now. Is the API overloaded? > > > Dewald > > > On Oct 18, 2:58 pm, Ryan Sarver wrote: > >> Michael, > > >> We are still working on getting the full picture, but once we have the > >> details I will report to the group what the issue was. > > >> Thanks for updating us. > > >> Best, Ryan > > >> On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer wrote: > >> > It is working for me. Would you mind sharing with the group what exactly > >> > happened? > >> > Thanks. > >> > Michael > > >> > On Oct 18, 2009, at 10:53 AM, Atul Kulkarni > >> > wrote: > > >> > Works Fine... Duluth, MN. > > >> > On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver > >> > wrote: > > >> >> I wanted to check in and see if everyone is back to normal? We think > >> >> things have been fixed but its hard to confirm without your help. > > >> >> Let me know if you are still experiencing any issues and if so, where > >> >> you are located. > > >> >> Best, Ryan > > >> >> On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius > >> >> wrote: > > >> >> > Same here. Can connect again. > > >> >> > On Oct 18, 2:46 pm, Michael Steuer wrote: > >> >> >> The situation seems to have been resolved, at least for me, as of a > >> >> >> few minutes ago. My Rackspace hosted servers can reach the API > >> >> >> again... > > >> >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius > >> >> >> wrote: > > >> >> >> > I don't really blame Twitter Ops for not knowing. It's probably a > >> >> >> > new > >> >> >> > edge defense that was installed by their service provider during > >> >> >> > Sunday night. > > >> >> >> > However, a while ago Alex said the Platform team were working on an > >> >> >> > external monitoring solution. Hopefully Ryan, who is now Director > >> >> >> > of > >> >> >> > the Platform team, will quickly move this forward to completion. > > >> >> >> > Dewald > > >> >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: > >> >> >> >> Amen to that. I find it kind of curious that as per John K., 5-6 > >> >> >> >> hours > >> >> >> >> into this issue, the Twitter ops team was still blissfully unaware > >> >> >> >> of > >> >> >> >> anything going on... Also weird that they apparently are unable to > >> >> >> >> reproduce the issue without our help, ie. they really haven't set > >> >> >> >> up > >> >> >> >> any monitoring outside of their network... > > >> >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius > >> >> >> >> wrote: > > >> >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features > >> >> >> >>> so > >> >> >> >>> that the Platform team can build a QoS system that monitors the > >> >> >> >>> API's > >> >> >> >>> availability and performance from the outside. That will enable > >> >> >> >>> Twitter to catch these kinds of issues long before we do. > > >> >> >> >>> Dewald > > >> >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: > >> >> >> This outage is now going on 7 hours. Any word from Twitter as to > >> >> >> an > >> >> >> ETA for resolution? > > >> >> >> On Oct 18, 2009, at 8:08 AM, John Meyer > >> >> >> wrote: > > >> >> >> > John Kalucki wrote: > >> >> >> >> And here's the next question: > > >> >> >> >> Is anyone having trouble from non-service, non-hosted > >> >> >> >> endpoints. In > >> >> >> >> other words, problem from home ISPs and desktop clients? > > >> >> >> >> -John Kalucki > >> >> >> >>http://twitter.com/jkalucki > >> >> >> >> Services, Twitter Inc. > > >> >> >> > Yep. (comcast, cannot access through either the website or > >> >> >> > desktop > >> >> >> > clients). > > >> > -- > >> > Regards, > >> > Atul Kulkarni > >> >www.d.umn.edu/~kulka053
[twitter-dev] Re: Laying the foundation for API versioning
Thanks, but still failing today.
[twitter-dev] Re: Problems Connecting to the API
Dewald, Can you produce some TCP dumps and requests with headers so we can better debug? Thanks, Ryan On Sun, Oct 18, 2009 at 12:05 PM, Dewald Pretorius wrote: > > I'm seeing lots of 502's now. Is the API overloaded? > > Dewald > > On Oct 18, 2:58 pm, Ryan Sarver wrote: >> Michael, >> >> We are still working on getting the full picture, but once we have the >> details I will report to the group what the issue was. >> >> Thanks for updating us. >> >> Best, Ryan >> >> On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer wrote: >> > It is working for me. Would you mind sharing with the group what exactly >> > happened? >> > Thanks. >> > Michael >> >> > On Oct 18, 2009, at 10:53 AM, Atul Kulkarni >> > wrote: >> >> > Works Fine... Duluth, MN. >> >> > On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: >> >> >> I wanted to check in and see if everyone is back to normal? We think >> >> things have been fixed but its hard to confirm without your help. >> >> >> Let me know if you are still experiencing any issues and if so, where >> >> you are located. >> >> >> Best, Ryan >> >> >> On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius >> >> wrote: >> >> >> > Same here. Can connect again. >> >> >> > On Oct 18, 2:46 pm, Michael Steuer wrote: >> >> >> The situation seems to have been resolved, at least for me, as of a >> >> >> few minutes ago. My Rackspace hosted servers can reach the API again... >> >> >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius >> >> >> wrote: >> >> >> >> > I don't really blame Twitter Ops for not knowing. It's probably a new >> >> >> > edge defense that was installed by their service provider during >> >> >> > Sunday night. >> >> >> >> > However, a while ago Alex said the Platform team were working on an >> >> >> > external monitoring solution. Hopefully Ryan, who is now Director of >> >> >> > the Platform team, will quickly move this forward to completion. >> >> >> >> > Dewald >> >> >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: >> >> >> >> Amen to that. I find it kind of curious that as per John K., 5-6 >> >> >> >> hours >> >> >> >> into this issue, the Twitter ops team was still blissfully unaware >> >> >> >> of >> >> >> >> anything going on... Also weird that they apparently are unable to >> >> >> >> reproduce the issue without our help, ie. they really haven't set up >> >> >> >> any monitoring outside of their network... >> >> >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius >> >> >> >> wrote: >> >> >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features >> >> >> >>> so >> >> >> >>> that the Platform team can build a QoS system that monitors the >> >> >> >>> API's >> >> >> >>> availability and performance from the outside. That will enable >> >> >> >>> Twitter to catch these kinds of issues long before we do. >> >> >> >> >>> Dewald >> >> >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: >> >> >> This outage is now going on 7 hours. Any word from Twitter as to >> >> >> an >> >> >> ETA for resolution? >> >> >> >> On Oct 18, 2009, at 8:08 AM, John Meyer >> >> >> wrote: >> >> >> >> > John Kalucki wrote: >> >> >> >> And here's the next question: >> >> >> >> >> Is anyone having trouble from non-service, non-hosted >> >> >> >> endpoints. In >> >> >> >> other words, problem from home ISPs and desktop clients? >> >> >> >> >> -John Kalucki >> >> >> >>http://twitter.com/jkalucki >> >> >> >> Services, Twitter Inc. >> >> >> >> > Yep. (comcast, cannot access through either the website or >> >> >> > desktop >> >> >> > clients). >> >> > -- >> > Regards, >> > Atul Kulkarni >> >www.d.umn.edu/~kulka053 >
[twitter-dev] Re: Problems Connecting to the API
I am connected via AT&T DSL from Ft. Pierce, FL. I am unable to connect with Firefox or TweetDeck. Firefox gives a time out error. On Oct 18, 10:56 am, John Kalucki wrote: > And here's the next question: > > Is anyone having trouble from non-service, non-hosted endpoints. In > other words, problem from home ISPs and desktop clients? > > -John Kaluckihttp://twitter.com/jkalucki > Services, Twitter Inc. > > On Oct 18, 7:55 am, John Kalucki wrote: > > > OK. I think we have enough traceroutes for now. Thanks for sending > > them in! > > > If we need more datapoints or information, I'll update this thread. > > > On Oct 18, 7:14 am, John Kalucki wrote: > > > > I don't see any operational issues from here, but I'm not an > > > operational guy. At first glance the system looks fine, and the > > > operational team isn't in response mode. This is puzzling. > > > > Seems like a connectivity issue upstream from twitter. At lest a few > > > developers: please send a traceroute to this list. Also, if you aren't > > > timing out, but rather are getting an HTTP error, send the response > > > headers. After say 4 or 5 responses, they'll probably have enough info > > > to triage this. > > > > -John Kaluckihttp://twitter.com/jkalucki > > > Services, Twitter Inc. > > > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > > > Does anyone else have problems connecting to the API at the moment > > > > (Sunday morning October 18)? > > > > > Dewald
[twitter-dev] Re: Search API Rate limiting - App Engine (again)
On Sun, Oct 18, 2009 at 8:09 AM, vivekpuri wrote: > > Will someone from Twitter please respond if there is an ETA to resolve > this issue. Work arounds can never be really as effective as the real > deal. Sorry, I thought it was clear from the previous email. There is no ETA because it's not going to be resolved. GAE does not use an IP infrastructure that is amicable to our rate-limiting logic, so if you want to integrate IP rate-limited calls into your web-based applications, you will need to either use the workaround stated earlier or use a hosting service that will let you use a static IP. -Chad
[twitter-dev] Re: Problems Connecting to the API
I'm seeing lots of 502's now. Is the API overloaded? Dewald On Oct 18, 2:58 pm, Ryan Sarver wrote: > Michael, > > We are still working on getting the full picture, but once we have the > details I will report to the group what the issue was. > > Thanks for updating us. > > Best, Ryan > > On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer wrote: > > It is working for me. Would you mind sharing with the group what exactly > > happened? > > Thanks. > > Michael > > > On Oct 18, 2009, at 10:53 AM, Atul Kulkarni wrote: > > > Works Fine... Duluth, MN. > > > On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: > > >> I wanted to check in and see if everyone is back to normal? We think > >> things have been fixed but its hard to confirm without your help. > > >> Let me know if you are still experiencing any issues and if so, where > >> you are located. > > >> Best, Ryan > > >> On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius > >> wrote: > > >> > Same here. Can connect again. > > >> > On Oct 18, 2:46 pm, Michael Steuer wrote: > >> >> The situation seems to have been resolved, at least for me, as of a > >> >> few minutes ago. My Rackspace hosted servers can reach the API again... > > >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius > >> >> wrote: > > >> >> > I don't really blame Twitter Ops for not knowing. It's probably a new > >> >> > edge defense that was installed by their service provider during > >> >> > Sunday night. > > >> >> > However, a while ago Alex said the Platform team were working on an > >> >> > external monitoring solution. Hopefully Ryan, who is now Director of > >> >> > the Platform team, will quickly move this forward to completion. > > >> >> > Dewald > > >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: > >> >> >> Amen to that. I find it kind of curious that as per John K., 5-6 > >> >> >> hours > >> >> >> into this issue, the Twitter ops team was still blissfully unaware > >> >> >> of > >> >> >> anything going on... Also weird that they apparently are unable to > >> >> >> reproduce the issue without our help, ie. they really haven't set up > >> >> >> any monitoring outside of their network... > > >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius > >> >> >> wrote: > > >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features > >> >> >>> so > >> >> >>> that the Platform team can build a QoS system that monitors the > >> >> >>> API's > >> >> >>> availability and performance from the outside. That will enable > >> >> >>> Twitter to catch these kinds of issues long before we do. > > >> >> >>> Dewald > > >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: > >> >> This outage is now going on 7 hours. Any word from Twitter as to > >> >> an > >> >> ETA for resolution? > > >> >> On Oct 18, 2009, at 8:08 AM, John Meyer > >> >> wrote: > > >> >> > John Kalucki wrote: > >> >> >> And here's the next question: > > >> >> >> Is anyone having trouble from non-service, non-hosted > >> >> >> endpoints. In > >> >> >> other words, problem from home ISPs and desktop clients? > > >> >> >> -John Kalucki > >> >> >>http://twitter.com/jkalucki > >> >> >> Services, Twitter Inc. > > >> >> > Yep. (comcast, cannot access through either the website or > >> >> > desktop > >> >> > clients). > > > -- > > Regards, > > Atul Kulkarni > >www.d.umn.edu/~kulka053
[twitter-dev] Re: Problems Connecting to the API
We're back in action from Slicehost in St. Louis and Rackspace in Dallas. Hayes On Sun, Oct 18, 2009 at 12:58 PM, Ryan Sarver wrote: > > Michael, > > We are still working on getting the full picture, but once we have the > details I will report to the group what the issue was. > > Thanks for updating us. > > Best, Ryan > > On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer wrote: >> It is working for me. Would you mind sharing with the group what exactly >> happened? >> Thanks. >> Michael >> >> >> >> On Oct 18, 2009, at 10:53 AM, Atul Kulkarni wrote: >> >> Works Fine... Duluth, MN. >> >> On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: >>> >>> I wanted to check in and see if everyone is back to normal? We think >>> things have been fixed but its hard to confirm without your help. >>> >>> Let me know if you are still experiencing any issues and if so, where >>> you are located. >>> >>> Best, Ryan >>> >>> On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius >>> wrote: >>> > >>> > Same here. Can connect again. >>> > >>> > On Oct 18, 2:46 pm, Michael Steuer wrote: >>> >> The situation seems to have been resolved, at least for me, as of a >>> >> few minutes ago. My Rackspace hosted servers can reach the API again... >>> >> >>> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius >>> >> wrote: >>> >> >>> >> >>> >> >>> >> > I don't really blame Twitter Ops for not knowing. It's probably a new >>> >> > edge defense that was installed by their service provider during >>> >> > Sunday night. >>> >> >>> >> > However, a while ago Alex said the Platform team were working on an >>> >> > external monitoring solution. Hopefully Ryan, who is now Director of >>> >> > the Platform team, will quickly move this forward to completion. >>> >> >>> >> > Dewald >>> >> >>> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: >>> >> >> Amen to that. I find it kind of curious that as per John K., 5-6 >>> >> >> hours >>> >> >> into this issue, the Twitter ops team was still blissfully unaware >>> >> >> of >>> >> >> anything going on... Also weird that they apparently are unable to >>> >> >> reproduce the issue without our help, ie. they really haven't set up >>> >> >> any monitoring outside of their network... >>> >> >>> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius >>> >> >> wrote: >>> >> >>> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features >>> >> >>> so >>> >> >>> that the Platform team can build a QoS system that monitors the >>> >> >>> API's >>> >> >>> availability and performance from the outside. That will enable >>> >> >>> Twitter to catch these kinds of issues long before we do. >>> >> >>> >> >>> Dewald >>> >> >>> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: >>> >> This outage is now going on 7 hours. Any word from Twitter as to >>> >> an >>> >> ETA for resolution? >>> >> >>> >> On Oct 18, 2009, at 8:08 AM, John Meyer >>> >> wrote: >>> >> >>> >> > John Kalucki wrote: >>> >> >> And here's the next question: >>> >> >>> >> >> Is anyone having trouble from non-service, non-hosted >>> >> >> endpoints. In >>> >> >> other words, problem from home ISPs and desktop clients? >>> >> >>> >> >> -John Kalucki >>> >> >>http://twitter.com/jkalucki >>> >> >> Services, Twitter Inc. >>> >> >>> >> > Yep. (comcast, cannot access through either the website or >>> >> > desktop >>> >> > clients). >>> > >> >> >> >> -- >> Regards, >> Atul Kulkarni >> www.d.umn.edu/~kulka053 >> >
[twitter-dev] Re: Problems Connecting to the API
On Oct 18, 1:51 pm, Ryan Sarver wrote: > I wanted to check in and see if everyone is back to normal? We think > things have been fixed but its hard to confirm without your help. I think everything is back to normal now. This is a very useful site to ping Twitter from around the world: http://just-ping.com/index.php?vh=twitter.com&c=&s=ping! Just minutes ago it was showing 100 % packet loss from Austin and Chicago.
[twitter-dev] Re: Problems Connecting to the API
Twitter just came back 2 minutes in Chicago.
[twitter-dev] Re: Problems Connecting to the API
Michael, We are still working on getting the full picture, but once we have the details I will report to the group what the issue was. Thanks for updating us. Best, Ryan On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer wrote: > It is working for me. Would you mind sharing with the group what exactly > happened? > Thanks. > Michael > > > > On Oct 18, 2009, at 10:53 AM, Atul Kulkarni wrote: > > Works Fine... Duluth, MN. > > On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: >> >> I wanted to check in and see if everyone is back to normal? We think >> things have been fixed but its hard to confirm without your help. >> >> Let me know if you are still experiencing any issues and if so, where >> you are located. >> >> Best, Ryan >> >> On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius >> wrote: >> > >> > Same here. Can connect again. >> > >> > On Oct 18, 2:46 pm, Michael Steuer wrote: >> >> The situation seems to have been resolved, at least for me, as of a >> >> few minutes ago. My Rackspace hosted servers can reach the API again... >> >> >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius >> >> wrote: >> >> >> >> >> >> >> >> > I don't really blame Twitter Ops for not knowing. It's probably a new >> >> > edge defense that was installed by their service provider during >> >> > Sunday night. >> >> >> >> > However, a while ago Alex said the Platform team were working on an >> >> > external monitoring solution. Hopefully Ryan, who is now Director of >> >> > the Platform team, will quickly move this forward to completion. >> >> >> >> > Dewald >> >> >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: >> >> >> Amen to that. I find it kind of curious that as per John K., 5-6 >> >> >> hours >> >> >> into this issue, the Twitter ops team was still blissfully unaware >> >> >> of >> >> >> anything going on... Also weird that they apparently are unable to >> >> >> reproduce the issue without our help, ie. they really haven't set up >> >> >> any monitoring outside of their network... >> >> >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius >> >> >> wrote: >> >> >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features >> >> >>> so >> >> >>> that the Platform team can build a QoS system that monitors the >> >> >>> API's >> >> >>> availability and performance from the outside. That will enable >> >> >>> Twitter to catch these kinds of issues long before we do. >> >> >> >> >>> Dewald >> >> >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: >> >> This outage is now going on 7 hours. Any word from Twitter as to >> >> an >> >> ETA for resolution? >> >> >> >> On Oct 18, 2009, at 8:08 AM, John Meyer >> >> wrote: >> >> >> >> > John Kalucki wrote: >> >> >> And here's the next question: >> >> >> >> >> Is anyone having trouble from non-service, non-hosted >> >> >> endpoints. In >> >> >> other words, problem from home ISPs and desktop clients? >> >> >> >> >> -John Kalucki >> >> >>http://twitter.com/jkalucki >> >> >> Services, Twitter Inc. >> >> >> >> > Yep. (comcast, cannot access through either the website or >> >> > desktop >> >> > clients). >> > > > > > -- > Regards, > Atul Kulkarni > www.d.umn.edu/~kulka053 >
[twitter-dev] Re: Problems Connecting to the API
I am now able to connect to twitter here in Wisconsin. ISP is TDS Josh
[twitter-dev] Re: Problems Connecting to the API
It is working for me. Would you mind sharing with the group what exactly happened? Thanks. Michael On Oct 18, 2009, at 10:53 AM, Atul Kulkarni wrote: Works Fine... Duluth, MN. On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: I wanted to check in and see if everyone is back to normal? We think things have been fixed but its hard to confirm without your help. Let me know if you are still experiencing any issues and if so, where you are located. Best, Ryan On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius wrote: > > Same here. Can connect again. > > On Oct 18, 2:46 pm, Michael Steuer wrote: >> The situation seems to have been resolved, at least for me, as of a >> few minutes ago. My Rackspace hosted servers can reach the API again... >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius wrote: >> >> >> >> > I don't really blame Twitter Ops for not knowing. It's probably a new >> > edge defense that was installed by their service provider during >> > Sunday night. >> >> > However, a while ago Alex said the Platform team were working on an >> > external monitoring solution. Hopefully Ryan, who is now Director of >> > the Platform team, will quickly move this forward to completion. >> >> > Dewald >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: >> >> Amen to that. I find it kind of curious that as per John K., 5-6 >> >> hours >> >> into this issue, the Twitter ops team was still blissfully unaware of >> >> anything going on... Also weird that they apparently are unable to >> >> reproduce the issue without our help, ie. they really haven't set up >> >> any monitoring outside of their network... >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius >> >> wrote: >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features so >> >>> that the Platform team can build a QoS system that monitors the >> >>> API's >> >>> availability and performance from the outside. That will enable >> >>> Twitter to catch these kinds of issues long before we do. >> >> >>> Dewald >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: >> This outage is now going on 7 hours. Any word from Twitter as to an >> ETA for resolution? >> >> On Oct 18, 2009, at 8:08 AM, John Meyer >> wrote: >> >> > John Kalucki wrote: >> >> And here's the next question: >> >> >> Is anyone having trouble from non-service, non-hosted >> >> endpoints. In >> >> other words, problem from home ISPs and desktop clients? >> >> >> -John Kalucki >> >>http://twitter.com/jkalucki >> >> Services, Twitter Inc. >> >> > Yep. (comcast, cannot access through either the website or desktop >> > clients). > -- Regards, Atul Kulkarni www.d.umn.edu/~kulka053
[twitter-dev] Re: Problems Connecting to the API
Works Fine... Duluth, MN. On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver wrote: > > I wanted to check in and see if everyone is back to normal? We think > things have been fixed but its hard to confirm without your help. > > Let me know if you are still experiencing any issues and if so, where > you are located. > > Best, Ryan > > On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius > wrote: > > > > Same here. Can connect again. > > > > On Oct 18, 2:46 pm, Michael Steuer wrote: > >> The situation seems to have been resolved, at least for me, as of a > >> few minutes ago. My Rackspace hosted servers can reach the API again... > >> > >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius > wrote: > >> > >> > >> > >> > I don't really blame Twitter Ops for not knowing. It's probably a new > >> > edge defense that was installed by their service provider during > >> > Sunday night. > >> > >> > However, a while ago Alex said the Platform team were working on an > >> > external monitoring solution. Hopefully Ryan, who is now Director of > >> > the Platform team, will quickly move this forward to completion. > >> > >> > Dewald > >> > >> > On Oct 18, 1:30 pm, Michael Steuer wrote: > >> >> Amen to that. I find it kind of curious that as per John K., 5-6 > >> >> hours > >> >> into this issue, the Twitter ops team was still blissfully unaware of > >> >> anything going on... Also weird that they apparently are unable to > >> >> reproduce the issue without our help, ie. they really haven't set up > >> >> any monitoring outside of their network... > >> > >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius > >> >> wrote: > >> > >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features so > >> >>> that the Platform team can build a QoS system that monitors the > >> >>> API's > >> >>> availability and performance from the outside. That will enable > >> >>> Twitter to catch these kinds of issues long before we do. > >> > >> >>> Dewald > >> > >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: > >> This outage is now going on 7 hours. Any word from Twitter as to an > >> ETA for resolution? > >> > >> On Oct 18, 2009, at 8:08 AM, John Meyer > >> wrote: > >> > >> > John Kalucki wrote: > >> >> And here's the next question: > >> > >> >> Is anyone having trouble from non-service, non-hosted > >> >> endpoints. In > >> >> other words, problem from home ISPs and desktop clients? > >> > >> >> -John Kalucki > >> >>http://twitter.com/jkalucki > >> >> Services, Twitter Inc. > >> > >> > Yep. (comcast, cannot access through either the website or desktop > >> > clients). > > > -- Regards, Atul Kulkarni www.d.umn.edu/~kulka053
[twitter-dev] Re: Problems Connecting to the API
I wanted to check in and see if everyone is back to normal? We think things have been fixed but its hard to confirm without your help. Let me know if you are still experiencing any issues and if so, where you are located. Best, Ryan On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius wrote: > > Same here. Can connect again. > > On Oct 18, 2:46 pm, Michael Steuer wrote: >> The situation seems to have been resolved, at least for me, as of a >> few minutes ago. My Rackspace hosted servers can reach the API again... >> >> On Oct 18, 2009, at 10:35 AM, Dewald Pretorius wrote: >> >> >> >> > I don't really blame Twitter Ops for not knowing. It's probably a new >> > edge defense that was installed by their service provider during >> > Sunday night. >> >> > However, a while ago Alex said the Platform team were working on an >> > external monitoring solution. Hopefully Ryan, who is now Director of >> > the Platform team, will quickly move this forward to completion. >> >> > Dewald >> >> > On Oct 18, 1:30 pm, Michael Steuer wrote: >> >> Amen to that. I find it kind of curious that as per John K., 5-6 >> >> hours >> >> into this issue, the Twitter ops team was still blissfully unaware of >> >> anything going on... Also weird that they apparently are unable to >> >> reproduce the issue without our help, ie. they really haven't set up >> >> any monitoring outside of their network... >> >> >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius >> >> wrote: >> >> >>> I'd be more than happy to wait longer for snazzy API 2.0 features so >> >>> that the Platform team can build a QoS system that monitors the >> >>> API's >> >>> availability and performance from the outside. That will enable >> >>> Twitter to catch these kinds of issues long before we do. >> >> >>> Dewald >> >> >>> On Oct 18, 12:47 pm, Michael Steuer wrote: >> This outage is now going on 7 hours. Any word from Twitter as to an >> ETA for resolution? >> >> On Oct 18, 2009, at 8:08 AM, John Meyer >> wrote: >> >> > John Kalucki wrote: >> >> And here's the next question: >> >> >> Is anyone having trouble from non-service, non-hosted >> >> endpoints. In >> >> other words, problem from home ISPs and desktop clients? >> >> >> -John Kalucki >> >>http://twitter.com/jkalucki >> >> Services, Twitter Inc. >> >> > Yep. (comcast, cannot access through either the website or desktop >> > clients). >
[twitter-dev] Re: Problems Connecting to the API
Setting up external monitoring isn't a huge undertaking. Their are plenty of existing services out there already. Even free ones like pingdom.com . Perhaps Twitter should set up a couple of those until they have their full QoS implementation in place. Pingdom for example would have started sending them emails and SMS messages at 2am pst this morning, when the issue started. They could have then escalated to their ISP and this whole thing wouldn't have lasted for close to 9 hours. On Oct 18, 2009, at 10:35 AM, Dewald Pretorius wrote: I don't really blame Twitter Ops for not knowing. It's probably a new edge defense that was installed by their service provider during Sunday night. However, a while ago Alex said the Platform team were working on an external monitoring solution. Hopefully Ryan, who is now Director of the Platform team, will quickly move this forward to completion. Dewald On Oct 18, 1:30 pm, Michael Steuer wrote: Amen to that. I find it kind of curious that as per John K., 5-6 hours into this issue, the Twitter ops team was still blissfully unaware of anything going on... Also weird that they apparently are unable to reproduce the issue without our help, ie. they really haven't set up any monitoring outside of their network... On Oct 18, 2009, at 9:05 AM, Dewald Pretorius wrote: I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer wrote: This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
Same here. Can connect again. On Oct 18, 2:46 pm, Michael Steuer wrote: > The situation seems to have been resolved, at least for me, as of a > few minutes ago. My Rackspace hosted servers can reach the API again... > > On Oct 18, 2009, at 10:35 AM, Dewald Pretorius wrote: > > > > > I don't really blame Twitter Ops for not knowing. It's probably a new > > edge defense that was installed by their service provider during > > Sunday night. > > > However, a while ago Alex said the Platform team were working on an > > external monitoring solution. Hopefully Ryan, who is now Director of > > the Platform team, will quickly move this forward to completion. > > > Dewald > > > On Oct 18, 1:30 pm, Michael Steuer wrote: > >> Amen to that. I find it kind of curious that as per John K., 5-6 > >> hours > >> into this issue, the Twitter ops team was still blissfully unaware of > >> anything going on... Also weird that they apparently are unable to > >> reproduce the issue without our help, ie. they really haven't set up > >> any monitoring outside of their network... > > >> On Oct 18, 2009, at 9:05 AM, Dewald Pretorius > >> wrote: > > >>> I'd be more than happy to wait longer for snazzy API 2.0 features so > >>> that the Platform team can build a QoS system that monitors the > >>> API's > >>> availability and performance from the outside. That will enable > >>> Twitter to catch these kinds of issues long before we do. > > >>> Dewald > > >>> On Oct 18, 12:47 pm, Michael Steuer wrote: > This outage is now going on 7 hours. Any word from Twitter as to an > ETA for resolution? > > On Oct 18, 2009, at 8:08 AM, John Meyer > wrote: > > > John Kalucki wrote: > >> And here's the next question: > > >> Is anyone having trouble from non-service, non-hosted > >> endpoints. In > >> other words, problem from home ISPs and desktop clients? > > >> -John Kalucki > >>http://twitter.com/jkalucki > >> Services, Twitter Inc. > > > Yep. (comcast, cannot access through either the website or desktop > > clients).
[twitter-dev] Re: Problems Connecting to the API
The situation seems to have been resolved, at least for me, as of a few minutes ago. My Rackspace hosted servers can reach the API again... On Oct 18, 2009, at 10:35 AM, Dewald Pretorius wrote: I don't really blame Twitter Ops for not knowing. It's probably a new edge defense that was installed by their service provider during Sunday night. However, a while ago Alex said the Platform team were working on an external monitoring solution. Hopefully Ryan, who is now Director of the Platform team, will quickly move this forward to completion. Dewald On Oct 18, 1:30 pm, Michael Steuer wrote: Amen to that. I find it kind of curious that as per John K., 5-6 hours into this issue, the Twitter ops team was still blissfully unaware of anything going on... Also weird that they apparently are unable to reproduce the issue without our help, ie. they really haven't set up any monitoring outside of their network... On Oct 18, 2009, at 9:05 AM, Dewald Pretorius wrote: I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer wrote: This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
I don't really blame Twitter Ops for not knowing. It's probably a new edge defense that was installed by their service provider during Sunday night. However, a while ago Alex said the Platform team were working on an external monitoring solution. Hopefully Ryan, who is now Director of the Platform team, will quickly move this forward to completion. Dewald On Oct 18, 1:30 pm, Michael Steuer wrote: > Amen to that. I find it kind of curious that as per John K., 5-6 hours > into this issue, the Twitter ops team was still blissfully unaware of > anything going on... Also weird that they apparently are unable to > reproduce the issue without our help, ie. they really haven't set up > any monitoring outside of their network... > > On Oct 18, 2009, at 9:05 AM, Dewald Pretorius wrote: > > > > > I'd be more than happy to wait longer for snazzy API 2.0 features so > > that the Platform team can build a QoS system that monitors the API's > > availability and performance from the outside. That will enable > > Twitter to catch these kinds of issues long before we do. > > > Dewald > > > On Oct 18, 12:47 pm, Michael Steuer wrote: > >> This outage is now going on 7 hours. Any word from Twitter as to an > >> ETA for resolution? > > >> On Oct 18, 2009, at 8:08 AM, John Meyer > >> wrote: > > >>> John Kalucki wrote: > And here's the next question: > > Is anyone having trouble from non-service, non-hosted endpoints. In > other words, problem from home ISPs and desktop clients? > > -John Kalucki > http://twitter.com/jkalucki > Services, Twitter Inc. > > >>> Yep. (comcast, cannot access through either the website or desktop > >>> clients).
[twitter-dev] Re: Problems Connecting to the API
Just for the record, +1 from Slicehost in St. Louis and Rackspace in Dallas. It's been happening since around 4am central. Hayes On Sun, Oct 18, 2009 at 11:30 AM, Michael Steuer wrote: > > Amen to that. I find it kind of curious that as per John K., 5-6 hours into > this issue, the Twitter ops team was still blissfully unaware of anything > going on... Also weird that they apparently are unable to reproduce the > issue without our help, ie. they really haven't set up any monitoring > outside of their network... > > > > On Oct 18, 2009, at 9:05 AM, Dewald Pretorius wrote: > >> >> I'd be more than happy to wait longer for snazzy API 2.0 features so >> that the Platform team can build a QoS system that monitors the API's >> availability and performance from the outside. That will enable >> Twitter to catch these kinds of issues long before we do. >> >> Dewald >> >> On Oct 18, 12:47 pm, Michael Steuer wrote: >>> >>> This outage is now going on 7 hours. Any word from Twitter as to an >>> ETA for resolution? >>> >>> On Oct 18, 2009, at 8:08 AM, John Meyer wrote: >>> >>> >>> John Kalucki wrote: > > And here's the next question: >>> > Is anyone having trouble from non-service, non-hosted endpoints. In > other words, problem from home ISPs and desktop clients? >>> > -John Kalucki > http://twitter.com/jkalucki > Services, Twitter Inc. >>> Yep. (comcast, cannot access through either the website or desktop clients). >
[twitter-dev] Re: Search API created_at date formatting
> I'm having problems with my code because it looks like the search > method is returning the created_at date in the following format: Fri, > 16 Oct 2009 16:40:25 + > > Everything else, and the documentation is using this format: Tue Feb > 24 16:38:44 + 2009 > > Is this being fixed? Yes, this is known. Twitter has already stated that they will merge these formats and other differences between Search API and regular timeline results in a future API version (IDNSOWFT). -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Sarcasm is a spiritual gift. -- Paul Austin
[twitter-dev] Search API created_at date formatting
I'm having problems with my code because it looks like the search method is returning the created_at date in the following format: Fri, 16 Oct 2009 16:40:25 + Everything else, and the documentation is using this format: Tue Feb 24 16:38:44 + 2009 Is this being fixed?
[twitter-dev] Re: Problems Connecting to the API
Desktop via Comcast, Chicago, local times: -last successful timeline call at 3:50am -one search query got a response, at 7am -no access to web site Michael D. Ivey wrote: > > Yes. Unable to connect via Tweetie from home (one of my traceroutes > was from home) and lots of reports from iPhone, AT&T and Comcast users > in Southeast. > > Sent from my iPhone > > On Oct 18, 2009, at 9:56 AM, John Kalucki wrote: > >> >> And here's the next question: >> >> Is anyone having trouble from non-service, non-hosted endpoints. In >> other words, problem from home ISPs and desktop clients? >> >> -John Kalucki >> http://twitter.com/jkalucki >> Services, Twitter Inc. >> >> >> On Oct 18, 7:55 am, John Kalucki wrote: >>> OK. I think we have enough traceroutes for now. Thanks for sending >>> them in! >>> >>> If we need more datapoints or information, I'll update this thread. >>> >>> On Oct 18, 7:14 am, John Kalucki wrote: >>> I don't see any operational issues from here, but I'm not an operational guy. At first glance the system looks fine, and the operational team isn't in response mode. This is puzzling. >>> Seems like a connectivity issue upstream from twitter. At lest a few developers: please send a traceroute to this list. Also, if you aren't timing out, but rather are getting an HTTP error, send the response headers. After say 4 or 5 responses, they'll probably have enough info to triage this. >>> -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. >>> On Oct 18, 6:40 am, Dewald Pretorius wrote: >>> > Does anyone else have problems connecting to the API at the moment > (Sunday morning October 18)? >>> > Dewald >
[twitter-dev] Re: Problems Connecting to the API
Amen to that. I find it kind of curious that as per John K., 5-6 hours into this issue, the Twitter ops team was still blissfully unaware of anything going on... Also weird that they apparently are unable to reproduce the issue without our help, ie. they really haven't set up any monitoring outside of their network... On Oct 18, 2009, at 9:05 AM, Dewald Pretorius wrote: I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer wrote: This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
Completely dead from multiple ISPs (Level3 upstream) as well as AT&T in Minnesota.
[twitter-dev] Re: Problems Connecting to the API
I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer wrote: > This outage is now going on 7 hours. Any word from Twitter as to an > ETA for resolution? > > On Oct 18, 2009, at 8:08 AM, John Meyer wrote: > > > > > John Kalucki wrote: > >> And here's the next question: > > >> Is anyone having trouble from non-service, non-hosted endpoints. In > >> other words, problem from home ISPs and desktop clients? > > >> -John Kalucki > >>http://twitter.com/jkalucki > >> Services, Twitter Inc. > > > Yep. (comcast, cannot access through either the website or desktop > > clients).
[twitter-dev] Re: Problems Connecting to the API
This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
I only have two endpoints to test from. Hosted: fails. Home DSL: no problem. I have several iPhone clients, but I'm bot sure if they're proxies or connect to the API directly... On Oct 18, 2009, at 7:56 AM, John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 7:55 am, John Kalucki wrote: OK. I think we have enough traceroutes for now. Thanks for sending them in! If we need more datapoints or information, I'll update this thread. On Oct 18, 7:14 am, John Kalucki wrote: I don't see any operational issues from here, but I'm not an operational guy. At first glance the system looks fine, and the operational team isn't in response mode. This is puzzling. Seems like a connectivity issue upstream from twitter. At lest a few developers: please send a traceroute to this list. Also, if you aren't timing out, but rather are getting an HTTP error, send the response headers. After say 4 or 5 responses, they'll probably have enough info to triage this. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 6:40 am, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: Problems Connecting to the API
John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
On Oct 18, 10:56 am, John Kalucki wrote: > And here's the next question: > > Is anyone having trouble from non-service, non-hosted endpoints. In > other words, problem from home ISPs and desktop clients? Everything works fine from my home ISP in New York. But Twitter is completely inaccessible from our servers in Chicago: curl http://twitter.com/ curl: (7) couldn't connect to host
[twitter-dev] Re: connectivity problems
Me either. All sources say Twitter.com doesn't seem to be "down" but I can't get anything from the site.
[twitter-dev] Re: Problems Connecting to the API
Yes. Unable to connect via Tweetie from home (one of my traceroutes was from home) and lots of reports from iPhone, AT&T and Comcast users in Southeast. Sent from my iPhone On Oct 18, 2009, at 9:56 AM, John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 7:55 am, John Kalucki wrote: OK. I think we have enough traceroutes for now. Thanks for sending them in! If we need more datapoints or information, I'll update this thread. On Oct 18, 7:14 am, John Kalucki wrote: I don't see any operational issues from here, but I'm not an operational guy. At first glance the system looks fine, and the operational team isn't in response mode. This is puzzling. Seems like a connectivity issue upstream from twitter. At lest a few developers: please send a traceroute to this list. Also, if you aren't timing out, but rather are getting an HTTP error, send the response headers. After say 4 or 5 responses, they'll probably have enough info to triage this. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 6:40 am, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: Problems Connecting to the API
And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 7:55 am, John Kalucki wrote: > OK. I think we have enough traceroutes for now. Thanks for sending > them in! > > If we need more datapoints or information, I'll update this thread. > > On Oct 18, 7:14 am, John Kalucki wrote: > > > I don't see any operational issues from here, but I'm not an > > operational guy. At first glance the system looks fine, and the > > operational team isn't in response mode. This is puzzling. > > > Seems like a connectivity issue upstream from twitter. At lest a few > > developers: please send a traceroute to this list. Also, if you aren't > > timing out, but rather are getting an HTTP error, send the response > > headers. After say 4 or 5 responses, they'll probably have enough info > > to triage this. > > > -John Kaluckihttp://twitter.com/jkalucki > > Services, Twitter Inc. > > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > > Does anyone else have problems connecting to the API at the moment > > > (Sunday morning October 18)? > > > > Dewald
[twitter-dev] Re: Problems Connecting to the API
OK. I think we have enough traceroutes for now. Thanks for sending them in! If we need more datapoints or information, I'll update this thread. On Oct 18, 7:14 am, John Kalucki wrote: > I don't see any operational issues from here, but I'm not an > operational guy. At first glance the system looks fine, and the > operational team isn't in response mode. This is puzzling. > > Seems like a connectivity issue upstream from twitter. At lest a few > developers: please send a traceroute to this list. Also, if you aren't > timing out, but rather are getting an HTTP error, send the response > headers. After say 4 or 5 responses, they'll probably have enough info > to triage this. > > -John Kaluckihttp://twitter.com/jkalucki > Services, Twitter Inc. > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > Does anyone else have problems connecting to the API at the moment > > (Sunday morning October 18)? > > > Dewald
[twitter-dev] Re: Problems Connecting to the API
+1 also can not connect to twitter api from any of our servers. On Oct 18, 2009, at 10:32 AM, Mark Ng wrote: +1 can't connect from slicehost.com (I believe in St. Louis). 2009/10/18 Michael Ivey : Further info I've collected: Can't connect from: AT&T DSL in South Alabama AT&T iPhone network Northwest Florida, probably Comcast Other users in Atlanta Scoble reported various flakiness Servers at Slicehost in the St Louis datacenter Can connect from: Blackberry in Atlanta Seesmic CoTweet Facebook iPhones in CA (@jess updated via Echofon a little while ago) -- ivey On Sun, Oct 18, 2009 at 8:40 AM, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: Search API Rate limiting - App Engine (again)
Will someone from Twitter please respond if there is an ETA to resolve this issue. Work arounds can never be really as effective as the real deal.
[twitter-dev] Re: Problems Connecting to the API
NTT America is not responding to requests coming from certain IP addresses. According to my tests from a few different hosts, it seems that some nodes of ntt.net are not relaying requests for US-based IPs, but a few of Asian hosts that I tested from are able to reach twitter.com fine. On Oct 18, 9:40 pm, Dewald Pretorius wrote: > Does anyone else have problems connecting to the API at the moment > (Sunday morning October 18)? > > Dewald
[twitter-dev] Re: Problems Connecting to the API
+1 can't connect from slicehost.com (I believe in St. Louis). 2009/10/18 Michael Ivey : > Further info I've collected: > > Can't connect from: > > AT&T DSL in South Alabama > AT&T iPhone network > Northwest Florida, probably Comcast > Other users in Atlanta > Scoble reported various flakiness > Servers at Slicehost in the St Louis datacenter > > Can connect from: > > Blackberry in Atlanta > Seesmic > CoTweet > Facebook > iPhones in CA (@jess updated via Echofon a little while ago) > > -- ivey > > > On Sun, Oct 18, 2009 at 8:40 AM, Dewald Pretorius wrote: >> >> Does anyone else have problems connecting to the API at the moment >> (Sunday morning October 18)? >> >> Dewald > >
[twitter-dev] Re: Problems Connecting to the API
We also can't connect from Chicago. I think we also lost connectivity around 2am. traceroute to cnn.com (157.166.255.18), 30 hops max, 40 byte packets 1 ip131.67-202-65.static.steadfast.net (67.202.65.131) 0.393 ms 0.467 ms 0.507 ms 2 te-8-2.car3.Chicago1.Level3.net (4.71.101.1) 0.332 ms 0.370 ms 0.457 ms 3 ae-32-56.ebr2.Chicago1.Level3.net (4.68.101.190) 6.576 ms 6.813 ms 6.557 ms 4 ae-3.ebr2.Atlanta2.Level3.net (4.69.132.74) 29.152 ms 29.128 ms 29.121 ms 5 ae-11-51.car1.Atlanta1.Level3.net (4.68.103.2) 20.158 ms ae-21-52.car1.Atlanta1.Level3.net (4.68.103.34) 19.592 ms ae-11-51.car1.Atlanta1.Level3.net (4.68.103.2) 20.479 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
[twitter-dev] Re: Problems Connecting to the API
> So somewhere before you reach twitter.com, traceroute must get > blocked. I just did a traceroute from my home (Verizon DSL) where I > can access Twitter perfectly, and traceroute still doesn't complete: I wouldn't read too much into that. From what I remember of Twitter's infrastructure (IDNSOWFT), NTT is their provider, so you are reaching their network, and I would not be surprised if ICMP were blocked once you got through the outside NTT perimetre. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Seen on hand dryer: "Push button for a message from your congressman." -
[twitter-dev] Re: Problems Connecting to the API
So somewhere before you reach twitter.com, traceroute must get blocked. I just did a traceroute from my home (Verizon DSL) where I can access Twitter perfectly, and traceroute still doesn't complete: michael-steuers-computer:~ msteuer$ traceroute twitter.com traceroute to twitter.com (128.121.146.100), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.611 ms 0.311 ms 0.197 ms 2 10.35.27.1 (10.35.27.1) 21.969 ms 22.321 ms 21.706 ms 3 p0-3.lsanca-lcr-03.verizon-gni.net (130.81.34.248) 21.712 ms 21.478 ms 21.507 ms 4 so-6-1-2-0.lax01-bb-rtr1.verizon-gni.net (130.81.28.225) 21.958 ms 21.830 ms 22.000 ms 5 0.so-6-3-0.xt1.lax9.alter.net (152.63.10.153) 23.446 ms 23.323 ms 23.743 ms 6 0.so-5-1-0.xt1.lax7.alter.net (152.63.116.253) 48.239 ms 24.029 ms 23.228 ms 7 pos6-0.br2.lax7.alter.net (152.63.112.145) 23.472 ms 23.722 ms 23.467 ms 8 p64-6-1-3.r20.lsanca03.us.bb.gin.ntt.net (129.250.8.205) 25.215 ms 24.968 ms 24.735 ms 9 as-0.r21.snjsca04.us.bb.gin.ntt.net (129.250.4.96) 35.987 ms 36.747 ms 35.958 ms 10 po-2.r04.snjsca04.us.bb.gin.ntt.net (129.250.6.6) 36.516 ms 37.034 ms * 11 * * * So I don't know how helpful all these traceroute results are going to be for Twitter, given that both from networks that can connect, and those that can't the traceroutes fail in the "ntt.net" or "telia.net" networks On Oct 18, 7:33 am, TCI wrote: > Tracert disabled from host - fail! > But I assume that if we can't reach you, you should not be able to > reach us either? My server's IP is 174.120.0.108 (The Planet) > > On Oct 18, 8:14 am, John Kalucki wrote: > > > > > I don't see any operational issues from here, but I'm not an > > operational guy. At first glance the system looks fine, and the > > operational team isn't in response mode. This is puzzling. > > > Seems like a connectivity issue upstream from twitter. At lest a few > > developers: please send a traceroute to this list. Also, if you aren't > > timing out, but rather are getting an HTTP error, send the response > > headers. After say 4 or 5 responses, they'll probably have enough info > > to triage this. > > > -John Kaluckihttp://twitter.com/jkalucki > > Services, Twitter Inc. > > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > > Does anyone else have problems connecting to the API at the moment > > > (Sunday morning October 18)? > > > > Dewald
[twitter-dev] Re: Problems Connecting to the API
Time Warner NYC Tracing route to twitter.com [168.143.162.116] 4 8 ms 8 ms 7 ms gig10-0-0-nycmnya-rtr1.nyc.rr.com [24.29.157.98] 5 7 ms 8 ms 5 ms tenge-0-3-0-nwrknjmd-rtr.nyc.rr.com [24.29.97.6] 6 6 ms 8 ms 7 ms ae-4-0.cr0.nyc30.tbone.rr.com [66.109.6.78] 714 ms28 ms23 ms ae-4-0.cr0.dca20.tbone.rr.com [66.109.6.28] 822 ms13 ms11 ms ae-1-0.pr0.dca10.tbone.rr.com [66.109.6.165] 923 ms17 ms18 ms if-11-1.icore1.AEQ-Ashburn.as6453.net [206.82.139.53] 1018 ms ** ix-2-8.icore1.AEQ-Ashburn.as6453.net [206.82.139.46] 1113 ms14 ms11 ms ae-2.r21.asbnva01.us.bb.gin.ntt.net [129.250.2.98] 1213 ms14 ms11 ms xe-6-1.r00.asbnva02.us.bb.gin.ntt.net [129.250.3.29] 13 *** Request timed out. 1481 ms80 ms78 ms 129.250.6.242 1581 ms79 ms82 ms 128.121.150.133 1684 ms78 ms77 ms 168.143.162.85 1779 ms81 ms82 ms 168.143.162.116 Cheers, Dean
[twitter-dev] connectivity problems
I'm not able to connect to twitter via any interface or software.
[twitter-dev] Re: Problems Connecting to the API
I'm getting this from my slicehost servers. $ traceroute twitter.com traceroute to twitter.com (168.143.161.20), 30 hops max, 40 byte packets 1 67-207-128-2.slicehost.net (67.207.128.2) 0.191 ms 0.165 ms 0.153 ms 2 209-20-79-2.slicehost.net (209.20.79.2) 0.704 ms 0.776 ms 0.347 ms 3 ge-6-10-163.car1.StLouis1.Level3.net (4.53.160.241) 1.813 ms 1.747 ms 1.720 ms 4 ae-11-11.car2.StLouis1.Level3.net (4.69.132.186) 1.678 ms 1.680 ms 1.863 ms 5 ae-4-4.ebr2.Chicago1.Level3.net (4.69.132.190) 14.920 ms 14.921 ms 14.899 ms 6 ae-2-56.edge3.Chicago3.Level3.net (4.68.101.180) 21.901 ms ae-2-52.edge3.Chicago3.Level3.net (4.68.101.52) 21.860 ms ae-2-54.edge3.Chicago3.Level3.net (4.68.101.116) 7.653 ms 7 4.68.63.198 (4.68.63.198) 8.226 ms 7.614 ms 8.172 ms 8 ae-1.r21.chcgil09.us.bb.gin.ntt.net (129.250.3.8) 7.824 ms 7.650 ms 7.420 ms 9 as-1.r21.dllstx09.us.bb.gin.ntt.net (129.250.3.17) 30.882 ms 33.149 ms 33.468 ms 10 po-2.r01.dllstx09.us.bb.gin.ntt.net (129.250.4.42) 33.440 ms 33.412 ms 33.027 ms 11 * * * It's working from Freedom2surf ADSL in the UK. On Oct 18, 3:31 pm, Michael Steuer wrote: > On my end: my server (at Rackspace) can't connect to twitter.com... If I > enter API URLs into my browser at home (Verizon DSL), I connect just fine. > Here's a traceroute from rackspace: > > traceroute twitter.com > traceroute to twitter.com (168.143.161.20), 30 hops max, 60 byte packets > 1 xxx-xxx-xxx-xxx.static.cloud-ips.com (xxx.xxx.xxx.xxx) 4.000 ms 4.000 > ms 4.000 ms > 2 98.129.84.216 (98.129.84.216) 0.000 ms 0.000 ms 0.000 ms > 3 edge3-core7-vlan3307.dfw1.rackspace.net (174.143.123.115) 4.000 ms > 4.000 ms edge3-core7-vlan2307.dfw1.rackspace.net (174.143.123.113) 4.000 > ms > 4 dls-bb1-link.telia.net (213.248.88.173) 4.000 ms 4.000 ms 4.000 ms > 5 verio-ic-127187-dls-bb1.c.telia.net (213.248.81.62) 96.005 ms 96.005 > ms 96.005 ms > 6 * * * > > Based on my logs, this has been going on since before 2AM PST > > On Sun, Oct 18, 2009 at 7:23 AM, Dewald Pretorius wrote: > > > traceroute to twitter.com (168.143.162.100), 30 hops max, 40 byte > > packets > > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 1.351 ms 1.439 > > ms 1.464 ms > > 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.198 ms 0.229 > > ms 0.266 ms > > 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.444 ms > > et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) > > 0.224 ms et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.466 ms > > 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.519 ms > > et1-2.ibr02.hstntx2.theplanet.com (70.87.253.169) 0 > > .454 ms 0.522 ms > > 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 167.161 ms > > 167.045 ms 167.206 ms > > 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.185 ms > > 1.164 ms 1.180 ms > > 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.424 > > ms 6.331 ms 6.358 ms > > 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.400 ms > > 6.451 ms 6.489 ms > > 9 * * * > > > -- > > > traceroute to twitter.com (168.143.162.116), 30 hops max, 40 byte > > packets > > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.387 ms 0.432 > > ms 0.475 ms > > 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.211 ms 0.257 > > ms 0.273 ms > > 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.472 ms > > et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) > > 0.221 ms 0.249 ms > > 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.404 ms 0.466 > > ms 0.553 ms > > 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 107.597 ms > > 107.679 ms 107.742 ms > > 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.136 ms > > 1.114 ms 1.035 ms > > 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.293 > > ms 8.708 ms 6.335 ms > > 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.433 ms > > 6.486 ms 6.535 ms > > 9 * * * > > > - > > > traceroute to twitter.com (168.143.162.36), 30 hops max, 40 byte > > packets > > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.429 ms 0.515 > > ms 0.567 ms > > 2 et2-5.ibr02.hstntx1.theplanet.com (207.218.245.5) 8.956 ms 8.986 > > ms 9.024 ms > > 3 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.439 ms 0.493 > > ms 0.546 ms > > 4 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 1.156 ms > > 1.206 ms 1.254 ms > > 5 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.114 ms > > 1.113 ms 1.131 ms > > 6 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.280 > > ms 6.256 ms 6.717 ms > > 7 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.377 ms > > 6.444 ms 6.499 ms > > 8 * * * > > > On Oct 18, 11:14 am, John Kalucki wrote: > > > I don't see any operational issues from here, but I'm not an > > > operational guy. At first glance the system looks fine, and the > > > operati
[twitter-dev] Re: Problems Connecting to the API
Tracert disabled from host - fail! But I assume that if we can't reach you, you should not be able to reach us either? My server's IP is 174.120.0.108 (The Planet) On Oct 18, 8:14 am, John Kalucki wrote: > I don't see any operational issues from here, but I'm not an > operational guy. At first glance the system looks fine, and the > operational team isn't in response mode. This is puzzling. > > Seems like a connectivity issue upstream from twitter. At lest a few > developers: please send a traceroute to this list. Also, if you aren't > timing out, but rather are getting an HTTP error, send the response > headers. After say 4 or 5 responses, they'll probably have enough info > to triage this. > > -John Kaluckihttp://twitter.com/jkalucki > Services, Twitter Inc. > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > Does anyone else have problems connecting to the API at the moment > > (Sunday morning October 18)? > > > Dewald
[twitter-dev] Re: Problems Connecting to the API
>From slicehost St. Louis: traceroute to twitter.com (168.143.161.20), 30 hops max, 60 byte packets 1 174.143.199.2 (174.143.199.2) 4.000 ms 4.000 ms 4.000 ms 2 98.129.84.172 (98.129.84.172) 4.000 ms 4.000 ms 4.000 ms 3 edge3-core7-vlan3307.dfw1.rackspace.net (174.143.123.115) 4.000 ms edge3-core7-vlan2307.dfw1.rackspace.net (174.143.123.113) 4.000 ms edge3-core7-vlan3307.dfw1.rackspace.net (174.143.123.115) 4.000 ms 4 dls-bb1-link.telia.net (213.248.88.173) 4.000 ms 4.000 ms 4.000 ms 5 verio-ic-127187-dls-bb1.c.telia.net (213.248.81.62) 4.000 ms 0.000 ms 0.000 ms 6 * * * traceroute to twitter.com (128.121.146.100), 30 hops max, 60 byte packets 1 174.143.199.2 (174.143.199.2) 4.000 ms 4.000 ms 4.000 ms 2 98.129.84.172 (98.129.84.172) 0.000 ms 0.000 ms 0.000 ms 3 98.129.84.178 (98.129.84.178) 104.006 ms 104.006 ms 104.006 ms 4 gateway.above.net (209.133.126.41) 40.002 ms 40.002 ms 40.002 ms 5 64.125.12.218.available.above.net (64.125.12.222) 4.000 ms 4.000 ms 4.000 ms 6 po-4.r02.dllstx09.us.bb.gin.ntt.net (129.250.2.93) 4.000 ms 4.000 ms 4.000 ms 7 xe-6-2.r01.dllstx09.us.bb.gin.ntt.net (129.250.4.174) 0.000 ms 0.000 ms 0.000 ms 8 * * * traceroute to twitter.com (168.143.162.116), 30 hops max, 60 byte packets 1 174.143.199.2 (174.143.199.2) 4.001 ms 4.001 ms 4.001 ms 2 98.129.84.172 (98.129.84.172) 0.000 ms 0.000 ms 0.000 ms 3 edge3-core7-vlan2307.dfw1.rackspace.net (174.143.123.113) 0.000 ms edge3-core7-vlan3307.dfw1.rackspace.net (174.143.123.115) 0.000 ms edge3-core7-vlan2307.dfw1.rackspace.net (174.143.123.113) 0.000 ms 4 dls-bb1-link.telia.net (213.248.88.173) 36.002 ms 36.002 ms 36.002 ms 5 verio-ic-127187-dls-bb1.c.telia.net (213.248.81.62) 100.005 ms 100.005 ms 100.005 ms 6 * * * >From AT&T DSL in Alabama: traceroute to twitter.com (168.143.162.116), 64 hops max, 40 byte packets 1 192.168.1.254 (192.168.1.254) 1.940 ms 2.202 ms 1.527 ms 2 72.157.0.8 (72.157.0.8) 8.080 ms 14.058 ms 11.673 ms 3 72.157.48.18 (72.157.48.18) 9.230 ms 8.685 ms 8.809 ms 4 72.157.48.243 (72.157.48.243) 16.000 ms 20.867 ms 17.520 ms 5 axr00mgm-so-0-1-0.bellsouth.net (65.83.239.80) 16.704 ms 32.931 ms 16.616 ms 6 205.152.170.27 (205.152.170.27) 32.417 ms * 16.573 ms 7 pxr00mna-so-1-0-0.bellsouth.net (65.83.236.62) 16.955 ms 17.866 ms 17.136 ms 8 12.83.2.32 (12.83.2.32) 16.129 ms 17.257 ms 16.649 ms 9 74.175.192.66 (74.175.192.66) 24.977 ms 25.824 ms 26.831 ms 10 cr2.attga.ip.att.net (12.122.140.186) 30.323 ms 26.766 ms cr1.attga.ip.att.net (12.122.141.186) 28.070 ms 11 ggr6.attga.ip.att.net (12.122.89.241) 25.732 ms 25.075 ms 25.209 ms 12 192.205.36.158 (192.205.36.158) 26.543 ms 25.269 ms 25.468 ms 13 p64-5-0-0.r21.dllstx09.us.bb.gin.ntt.net (129.250.5.26) 44.591 ms 44.821 ms 44.474 ms 14 * * * >From datacenter in downtown Atlanta: traceroute to twitter.com (168.143.162.36), 30 hops max, 38 byte packets 1 atl-datacenter-r2.capitalinternet.com (208.32.175.2) 0.964 ms 0.526 ms 0.712 ms 2 atl-downtown-r1.capitalinternet.com (199.0.160.1) 1.309 ms 1.567 ms 1.213 ms 3 199.0.160.20 (199.0.160.20) 1.063 ms 1.326 ms 1.090 ms 4 * * * -- ivey On Sun, Oct 18, 2009 at 9:14 AM, John Kalucki wrote: > > I don't see any operational issues from here, but I'm not an > operational guy. At first glance the system looks fine, and the > operational team isn't in response mode. This is puzzling. > > Seems like a connectivity issue upstream from twitter. At lest a few > developers: please send a traceroute to this list. Also, if you aren't > timing out, but rather are getting an HTTP error, send the response > headers. After say 4 or 5 responses, they'll probably have enough info > to triage this. > > -John Kalucki > http://twitter.com/jkalucki > Services, Twitter Inc. > > > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > Does anyone else have problems connecting to the API at the moment > > (Sunday morning October 18)? > > > > Dewald >
[twitter-dev] Re: Problems Connecting to the API
On my end: my server (at Rackspace) can't connect to twitter.com... If I enter API URLs into my browser at home (Verizon DSL), I connect just fine. Here's a traceroute from rackspace: traceroute twitter.com traceroute to twitter.com (168.143.161.20), 30 hops max, 60 byte packets 1 xxx-xxx-xxx-xxx.static.cloud-ips.com (xxx.xxx.xxx.xxx) 4.000 ms 4.000 ms 4.000 ms 2 98.129.84.216 (98.129.84.216) 0.000 ms 0.000 ms 0.000 ms 3 edge3-core7-vlan3307.dfw1.rackspace.net (174.143.123.115) 4.000 ms 4.000 ms edge3-core7-vlan2307.dfw1.rackspace.net (174.143.123.113) 4.000 ms 4 dls-bb1-link.telia.net (213.248.88.173) 4.000 ms 4.000 ms 4.000 ms 5 verio-ic-127187-dls-bb1.c.telia.net (213.248.81.62) 96.005 ms 96.005 ms 96.005 ms 6 * * * Based on my logs, this has been going on since before 2AM PST On Sun, Oct 18, 2009 at 7:23 AM, Dewald Pretorius wrote: > > traceroute to twitter.com (168.143.162.100), 30 hops max, 40 byte > packets > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 1.351 ms 1.439 > ms 1.464 ms > 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.198 ms 0.229 > ms 0.266 ms > 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.444 ms > et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) > 0.224 ms et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.466 ms > 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.519 ms > et1-2.ibr02.hstntx2.theplanet.com (70.87.253.169) 0 > .454 ms 0.522 ms > 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 167.161 ms > 167.045 ms 167.206 ms > 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.185 ms > 1.164 ms 1.180 ms > 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.424 > ms 6.331 ms 6.358 ms > 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.400 ms > 6.451 ms 6.489 ms > 9 * * * > > -- > > traceroute to twitter.com (168.143.162.116), 30 hops max, 40 byte > packets > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.387 ms 0.432 > ms 0.475 ms > 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.211 ms 0.257 > ms 0.273 ms > 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.472 ms > et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) > 0.221 ms 0.249 ms > 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.404 ms 0.466 > ms 0.553 ms > 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 107.597 ms > 107.679 ms 107.742 ms > 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.136 ms > 1.114 ms 1.035 ms > 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.293 > ms 8.708 ms 6.335 ms > 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.433 ms > 6.486 ms 6.535 ms > 9 * * * > > - > > traceroute to twitter.com (168.143.162.36), 30 hops max, 40 byte > packets > 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.429 ms 0.515 > ms 0.567 ms > 2 et2-5.ibr02.hstntx1.theplanet.com (207.218.245.5) 8.956 ms 8.986 > ms 9.024 ms > 3 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.439 ms 0.493 > ms 0.546 ms > 4 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 1.156 ms > 1.206 ms 1.254 ms > 5 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.114 ms > 1.113 ms 1.131 ms > 6 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.280 > ms 6.256 ms 6.717 ms > 7 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.377 ms > 6.444 ms 6.499 ms > 8 * * * > > > On Oct 18, 11:14 am, John Kalucki wrote: > > I don't see any operational issues from here, but I'm not an > > operational guy. At first glance the system looks fine, and the > > operational team isn't in response mode. This is puzzling. > > > > Seems like a connectivity issue upstream from twitter. At lest a few > > developers: please send a traceroute to this list. Also, if you aren't > > timing out, but rather are getting an HTTP error, send the response > > headers. After say 4 or 5 responses, they'll probably have enough info > > to triage this. > > > > -John Kaluckihttp://twitter.com/jkalucki > > Services, Twitter Inc. > > > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > > > Does anyone else have problems connecting to the API at the moment > > > (Sunday morning October 18)? > > > > > Dewald >
[twitter-dev] Re: Problems Connecting to the API
traceroute to twitter.com (168.143.162.100), 30 hops max, 40 byte packets 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 1.351 ms 1.439 ms 1.464 ms 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.198 ms 0.229 ms 0.266 ms 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.444 ms et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) 0.224 ms et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.466 ms 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.519 ms et1-2.ibr02.hstntx2.theplanet.com (70.87.253.169) 0 .454 ms 0.522 ms 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 167.161 ms 167.045 ms 167.206 ms 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.185 ms 1.164 ms 1.180 ms 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.424 ms 6.331 ms 6.358 ms 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.400 ms 6.451 ms 6.489 ms 9 * * * -- traceroute to twitter.com (168.143.162.116), 30 hops max, 40 byte packets 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.387 ms 0.432 ms 0.475 ms 2 et2-5.ibr01.hstntx1.theplanet.com (207.218.223.5) 0.211 ms 0.257 ms 0.273 ms 3 et1-3.ibr01.hstntx2.theplanet.com (70.87.253.154) 0.472 ms et3-2.ibr02.hstntx1.theplanet.com (70.87.253.157) 0.221 ms 0.249 ms 4 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.404 ms 0.466 ms 0.553 ms 5 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 107.597 ms 107.679 ms 107.742 ms 6 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.136 ms 1.114 ms 1.035 ms 7 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.293 ms 8.708 ms 6.335 ms 8 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.433 ms 6.486 ms 6.535 ms 9 * * * - traceroute to twitter.com (168.143.162.36), 30 hops max, 40 byte packets 1 81.b5.85ae.static.theplanet.com (174.133.181.129) 0.429 ms 0.515 ms 0.567 ms 2 et2-5.ibr02.hstntx1.theplanet.com (207.218.245.5) 8.956 ms 8.986 ms 9.024 ms 3 et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58) 0.439 ms 0.493 ms 0.546 ms 4 xe-4-4.r03.hstntx01.us.bb.gin.ntt.net (128.241.1.5) 1.156 ms 1.206 ms 1.254 ms 5 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) 1.114 ms 1.113 ms 1.131 ms 6 p64-7-0-2.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) 6.280 ms 6.256 ms 6.717 ms 7 po-1.r01.dllstx09.us.bb.gin.ntt.net (129.250.3.74) 6.377 ms 6.444 ms 6.499 ms 8 * * * On Oct 18, 11:14 am, John Kalucki wrote: > I don't see any operational issues from here, but I'm not an > operational guy. At first glance the system looks fine, and the > operational team isn't in response mode. This is puzzling. > > Seems like a connectivity issue upstream from twitter. At lest a few > developers: please send a traceroute to this list. Also, if you aren't > timing out, but rather are getting an HTTP error, send the response > headers. After say 4 or 5 responses, they'll probably have enough info > to triage this. > > -John Kaluckihttp://twitter.com/jkalucki > Services, Twitter Inc. > > On Oct 18, 6:40 am, Dewald Pretorius wrote: > > > Does anyone else have problems connecting to the API at the moment > > (Sunday morning October 18)? > > > Dewald
[twitter-dev] Re: Problems Connecting to the API
I don't see any operational issues from here, but I'm not an operational guy. At first glance the system looks fine, and the operational team isn't in response mode. This is puzzling. Seems like a connectivity issue upstream from twitter. At lest a few developers: please send a traceroute to this list. Also, if you aren't timing out, but rather are getting an HTTP error, send the response headers. After say 4 or 5 responses, they'll probably have enough info to triage this. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 18, 6:40 am, Dewald Pretorius wrote: > Does anyone else have problems connecting to the API at the moment > (Sunday morning October 18)? > > Dewald
[twitter-dev] Re: Problems Connecting to the API
Further info I've collected: Can't connect from: - AT&T DSL in South Alabama - AT&T iPhone network - Northwest Florida, probably Comcast - Other users in Atlanta - Scoble reported various flakiness - Servers at Slicehost in the St Louis datacenter Can connect from: - Blackberry in Atlanta - Seesmic - CoTweet - Facebook - iPhones in CA (@jess updated via Echofon a little while ago) -- ivey On Sun, Oct 18, 2009 at 8:40 AM, Dewald Pretorius wrote: > > Does anyone else have problems connecting to the API at the moment > (Sunday morning October 18)? > > Dewald >
[twitter-dev] Re: Problems Connecting to the API
THANKS for posting - I've spent the last hour trying to figure this out and since there were not reports I thought it was me. Down from my server as well, although if I try the exact same calls that my server (in USA) is making from my desktop (in Costa Rica) they all return. This is what had me significantly confused. Maybe they have different servers for each geo and only some areas are down? On Oct 18, 7:40 am, Dewald Pretorius wrote: > Does anyone else have problems connecting to the API at the moment > (Sunday morning October 18)? > > Dewald
[twitter-dev] Re: Problems Connecting to the API
In fact, looking at my logs, the API was down since at least 2 AM Pacific (5 hours ago)... On Oct 18, 2009, at 6:40 AM, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: Problems Connecting to the API
Yes, not connecting at all here. Kust timing out. On Oct 18, 2009, at 6:40 AM, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: Problems Connecting to the API
Not just you. Every machine I've tried times out, but istwitterdown.com says No and Seesmic Web works. Seems to be connectivity issue. Sent from my iPhone On Oct 18, 2009, at 8:40 AM, Dewald Pretorius wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Problems Connecting to the API
Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Profile photo - Access Denied
Hi, I'm doing a Flash app using the Twitter Search API. In the ATOM feed there's a node containing the profile photo url. However for some users, when I try to get the photo I get a XML file similar to this: AccessDenied Access Denied 661A5450F0C3BC24 ZeVGawzEJVrKbgYDsRcNL2SWOxd0rkUmOM2GlwzGz2QHXgegiqUQLkgGicKKsuf/ Is this a bug? Or is there a workaround? Thanks in advance.
[twitter-dev] Re: Why have you removed the HTML/CSS badge/widget?
Yes, that is the one I mean. Well I am on the developer website because I found it through Google. And while I certainly know my way around HTML and CSS, any kind of programming is beyond the scope of my brain, so no I could not make my own widget without a lot of help. My widget didnt stop working, I just find it baffling that Twitter would remove access to a text/css widget on their website (and by access I mean remove all internal links and mention of it), and instead provide only bloated, impossible to truly customize flash widgets, especially given the minimalist nature of the Twitter service. On Oct 17, 11:24 pm, Scott Haneda wrote: > Not sure I understand, you mean like this > one:http://twitter.com/widgets/html_widget > > Either way, text only widget, you being on a developer mailing list, I > am sure in all honestly, a few lines, maybe 10 lines or so, and you > could have a widget to your liking. > > Whatever old widget your refer to, has to be in use by others, they > could not just take it away, as that would break everyones sites who > included it in their website. > > I suspect they may have moved it elsewhere, but I am certain the old > widget still works. There are also 10's of websites that have twitter > widgets, from simple to complex. > > Did your widgets stop working? If not, just copy the source from > those and keep using them, they will continue to work. > -- > Scott * If you contact me off list replace talklists@ with scott@ * > > On Oct 17, 2009, at 10:13 PM, Jonathan Timar wrote: > > > I am referring to the text only version of > > this:http://twitter.com/widgets/which_widget > > , > > which is oddly still present on the Twitter website (I found it after > > some in depth Googling) but no longer linked to or referenced in any > > way, in favour of this page:http://twitter.com/goodieswhich features > > some far less useful and customizable widgets. > > > What is the reasoning behind this? Does Twitter really think that > > there is no demand for a simply, fully CSS styleable widget?
[twitter-dev] Re: Bug? Updates > 140 characters return success with prior update payload
> On Sat, Oct 17, 2009 at 10:41 AM, Marc Mims wrote: > > Updates longer than 140 characters should be forcibly truncated > > according to the documentation. Instead, the update call returns with > > a 200 status and the payload contains the prior update. > > > > Has there been a change to the API or is this a bug. On Sat, Oct 17, 2009 at 05:15:42PM -0500, Josh Roesslein wrote: > This is a change in the API confirmed by one of twitter's API members. > The docs should be updated soon. In that case, is there any change (planned or current) which will indicate when this has happened, or if the update has been rejected for any other reason? Failing silently does not seem appropriate, particularly when the failure returns the user's previous status. -- Dave Sherohman
[twitter-dev] Re: Draft of List API documentation
Multiple identical list create requests result in multiple lists, differing in slug/url/full name. Perhaps it should ignore, or return an error? $ curl -u dcbriccetti -d "name=Scala" http://twitter.com/dcbriccetti/lists.xml 29926 Scala @dcbriccetti/scala-2 scala-2 ... $ curl -u dcbriccetti -d "name=Scala" http://twitter.com/dcbriccetti/lists.xml 29927 Scala @dcbriccetti/scala-3 scala-3 ...
[twitter-dev] Re: Draft of List API documentation
Bulk add would be great. Here’s a log from doing individual adds. Notice there were many over capacity errors. And that it took about a minute 42 to add about 60 users. If I could do all in one request, perhaps that would help reduce the over capacity errors. I’m enjoying lists. Thanks for the feature. 00:19:04,692 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=52061552 00:19:05,291 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=19757713 ... 00:19:28,647 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=31206658 00:19:28,802 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=7401782 00:19:37,686 TwitterException - Code: 503, Title: Twitter / Over capacity 00:19:37,687 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=12173192 00:19:43,698 TwitterException - Code: 503, Title: Twitter / Over capacity 00:19:43,699 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=6562002 00:19:44,803 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=45456164 ... 00:19:49,219 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=17334287 00:19:56,129 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=45966787 00:20:01,698 TwitterException - Code: 503, Title: Twitter / Over capacity 00:20:01,698 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=17779075 00:20:02,341 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=8858812 ... 00:20:17,320 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=19044984 00:20:17,734 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=648533 00:20:23,526 TwitterException - Code: 503, Title: Twitter / Over capacity 00:20:23,526 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=19142351 00:20:24,144 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=10759032 ... 00:20:42,440 dcbriccetti POST http://api.twitter.com/1/dcbriccetti/scala/members.xml id=19418890
