Hi there,

Thanks for the follow up Eric. Based on my reading about libcurl failure to connect certainly looks like it would return HTTP 0. I wish I could just say "not my issue" and move on at this point, but I'm not That Guy™. Failure to connect to twitter.com can either be some network issue between our two sites or that your IP has been blacklisted [1]. In your case, Eric, I know we've talked before and I'm pretty sure you're not on the blacklist. The intermittent nature of your problem supports that. The same goes for Chris, 30% failure is not consistent with blacklisting.

In both of your cases it would be helpful if you can send me (off list) a full traceroute to twitter.com that shows the timeout. I'll get those in the hands of our operations folks and see if the problem is with our provider (who we can harass) or someone else. It may well be someone you two have in common, which is why we don't see more reports of the issue.

Thanks;
  — Matt Sanford

[1] - http://apiwiki.twitter.com/FAQ#IsmyIPbannedorblacklisted

On Feb 19, 2009, at 06:35 PM, Eric Blair wrote:


I've been seeing that a bit the past few days as well (it looks like
the email I sent to the list yesterday about curl multi was an HTTP
Status 0 issue).

We were outputting the curl output from our app to a file for a bit -
it definitely seemed like the cases with status code 0 weren't
communicating with Twitter - I've pasted some sample output at the end
of the email. The log describes the following situation - we batched 4
requests and, in this case, 2 succeeded and 2 failed. In this case,
the failures show up as Connection Timeout. I saw a few of these
happen live in our logs and the timeout was definitely shorter than
the value we set for CURLOPT_TIMEOUT. However, it might've been long
enough to hit the limit set for CURLOPT_CONNECTTIMEOUT. We're
increasing that value to see if improves the situation.

In other cases, we saw Host Not Found instead of Connection Timeout,
so I'm not certain if this will resolve the issue.

One thing we did notice is that it looks like we're getting some major
packet loss between our server and Twitter - one host was dropping 25%
of packets and the next host was dropping 11%. We thought that seemed
excessive and might've been contributing to the status 0 message.
Here's a sample of the problematic portion of the traceroute:

                                                                                
                        Packets                 Pings
                                                                                
                        Loss%   Snt             Last            Avg             
Best    Wrst    StDev
 8. xe-0-3-0.r21.chcgil09.us.bb.gin.ntt.net                             0.4%    
3526    4.0             4.8             
4.0             224.0   7.8
 9. p64-7-0-3.r20.snjsca04.us.bb.gin.ntt.net                    25.7%   3526    
56.0    55.3    
52.0    228.0   9.3
10. xe-1-3.r02.mlpsca01.us.bb.gin.ntt.net 11.1% 3526 52.0 68.6 52.0
564.0   44.5
11. mg-1.c00.mlpsca01.us.da.verio.net                                   0.4%    
3526    56.0    73.2    52.0    
4536.   92.4

Here's the curl output -

* About to connect() to www.twitter.com port 80 (#0)
*   Trying 128.121.146.100...
* About to connect() to www.twitter.com port 80 (#1)
*   Trying 128.121.146.100...
* About to connect() to www.twitter.com port 80 (#2)
*   Trying 128.121.146.100...
* About to connect() to www.twitter.com port 80 (#3)
*   Trying 128.121.146.100...

* Connected to www.twitter.com (128.121.146.100) port 80 (#2)
* Server auth using Basic with user '******'
GET /direct_messages.xml?count=25&since=Mon+Feb+16+03%3A07%3A36+
%2B0000+2009 HTTP/1.1

* Connected to www.twitter.com (128.121.146.100) port 80 (#3)
* Server auth using Basic with user '******'
GET /direct_messages/sent.xml?count=25&since=Mon+Feb
+16+03%3A07%3A36+%2B0000+2009 HTTP/1.1

< HTTP/1.1 200 OK
< Date: Thu, 19 Feb 2009 20:51:06 GMT
< Server: hi
< Last-Modified: Thu, 19 Feb 2009 20:51:06 GMT
< Status: 200 OK
< ETag: "8cbb8956513e515ff337bf304285829f"
< Pragma: no-cache
< Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
< Content-Type: application/xml; charset=utf-8
< Content-Length: 79
< Expires: Tue, 31 Mar 1981 05:00:00 GMT
< X-Revision: d50813e1759a5b669840a0ae553da67b69c67caf
< X-Transaction: 1235076666-28856-29642
< Set-Cookie: lang=en; path=/
< Set-Cookie: lang=en; path=/
< Set-Cookie:
_twitter_sess
=
BAh7CToTcGFzc3dvcmRfdG9rZW4iLWRiNDcwZjgzYWFlNjU5YTk5YmM1MjY1
%250AZjE4OTM5MzUwNDA2NWJlMjA6CXVzZXJpA%252F5d5ToHaWQiJTIyMmVmZmVlMjFk
%250ANWU4OWY0NGNmMWU1MzM2MTEzZWQ3IgpmbGFzaElDOidBY3Rpb25Db250cm9s
%250AbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA
--5bd0845e53637728605a15dd8c9fa4043cb5fea6; domain=.twitter.com; path=/
< Vary: Accept-Encoding
< Connection: close
<
* Expire cleared
* Closing connection #2

< HTTP/1.1 200 OK
< Date: Thu, 19 Feb 2009 20:51:06 GMT
< Server: hi
< Last-Modified: Thu, 19 Feb 2009 20:51:06 GMT
< Status: 200 OK
< ETag: "8cbb8956513e515ff337bf304285829f"
< Pragma: no-cache
< Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
< Content-Type: application/xml; charset=utf-8
< Content-Length: 79
< Expires: Tue, 31 Mar 1981 05:00:00 GMT
< X-Revision: d50813e1759a5b669840a0ae553da67b69c67caf
< X-Transaction: 1235076666-55169-28378
< Set-Cookie: lang=en; path=/
< Set-Cookie: lang=en; path=/
< Set-Cookie:
_twitter_sess
=
BAh7CToTcGFzc3dvcmRfdG9rZW4iLWRiNDcwZjgzYWFlNjU5YTk5YmM1MjY1
%250AZjE4OTM5MzUwNDA2NWJlMjA6CXVzZXJpA
%252F5d5ToHaWQiJTUwYjUxMDg1OGE2
%250AY2ZlYWNhYzE2MDQ1ZjlmMWRjZDRkIgpmbGFzaElDOidBY3Rpb25Db250cm9s
%250AbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--
d1e252a95e502fa449339582429e1703159e5d2f; domain=.twitter.com; path=/
< Vary: Accept-Encoding
< Connection: close
<
* Expire cleared
* Closing connection #3

* Expire cleared
* Expire cleared

* Connection time-out
* Closing connection #0

* Connection time-out
* Closing connection #1


On Feb 19, 2009, at 8:43 PM, Matt Sanford wrote:


Hi Chris,

  I've seen reports of this HTTP 0 before but I'm having trouble
making sense of it. There is no code in our system that returns 0,
at least not on purpose and I couldn't find anything in our apache
logs. A quick trip to Google shows that libcurl (used by the PHP
curl functions) returns 0 if it cannot connect. Are you able to make
the same request via the curl command line utility? If so, please
send along the output of curl -v (minus the Authorization header).

Thanks;
— Matt Sanford

[1] - http://stackoverflow.com/questions/290996/http-status-code-with-libcurl


On Feb 19, 2009, at 01:53 PM, Chris wrote:


Howdy,

I am making API calls to Twitter using PHP ('Arc90 Twitter API
Client'
Library) to update a users status, and about 3 out of 10 times CURL
returns a HTTP status code of 0 - with no other data returned.

But if I try again and again it will usually work within a few
repeats. Does anyone have any ideas about this?

Thanks for your help,

Chris.




Reply via email to