HTTP Timeout - how do i fix it?

Hi, im installing haxelib Lime. and i am getting these errors

C:\Users"MY PC">haxelib install lime
Failed. Triggering retry due to HTTP timeout
Failed. Triggering retry due to HTTP timeout
Failed. Triggering retry due to HTTP timeout
Error: Failed due to HTTP timeout after multiple retries

How do i fix it??

I think it’s normal now.

It was haxelib’s MySQL filled its 8Gi disk with its bin log, because the expire_logs_days default setting is 0 (i.e. keep all bin log forever). I’ve just resized the disk to 32Gi and set expire_logs_days to 1.

I will setup some more monitoring soon.

2 Likes

The current access status is still timeout.

Did the download actually start? If it’s just the download took too long to complete (e.g. when the Internet connection is slow), try the -notimeout param, e.g. haxelib install -notimeout lime.

It seems that it has nothing to do with this. Many people have encountered this problem.

@andyli Hi~ It can ping, But,
Haxelib cannot be accessed normally in China. Is there an IP interception error in the server settings?

It’s the first time I heard haxelib connection problem specific to China.

We’re using Digital Ocean Spaces for the haxelib file storage. There is not much to config for its CDN, so I don’t think we can change much from our side.

Would you post the output of the command as follows?

curl -vL https://lib.haxe.org/files/3.0/jQueryExtern-3,3,0.zip
curl -vL https://lib.haxe.org/files/3.0/jQueryExtern-3,3,0.zip
*   Trying 46.101.64.224:443...
* Connected to lib.haxe.org (46.101.64.224) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=do-lib.haxe.org
*  start date: May 25 10:58:28 2022 GMT
*  expire date: Aug 23 10:58:27 2022 GMT
*  subjectAltName: host "lib.haxe.org" matched cert's "lib.haxe.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x146011e00)
> GET /files/3.0/jQueryExtern-3,3,0.zip HTTP/2
> Host: lib.haxe.org
> user-agent: curl/7.77.0
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 302 
< date: Thu, 26 May 2022 22:39:48 GMT
< content-type: text/html
< content-length: 0
< location: https://haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com/files/3.0/jQueryExtern-3,3,0.zip
< strict-transport-security: max-age=15724800; includeSubDomains
< x-cache-status: MISS
< 
* Connection #0 to host lib.haxe.org left intact
* Issue another request to this URL: 'https://haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com/files/3.0/jQueryExtern-3,3,0.zip'
*   Trying 205.185.216.10:443...
* Connected to haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com (205.185.216.10) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com:443 
* Closing connection 1
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com:443 

@andyli Yes!

@andyli Is this an SSL error on the server? How to solve this problem?

I’ve opened a support ticket in Digital Ocean. They suggest try using a VPN and see if it can workaround the issue. It would also be useful to share the name of ISP and MTR from any of the affected system with Digital Ocean.

For info about MTR, see this guide: How To Use Traceroute and MTR to Diagnose Network Issues | DigitalOcean

To run MTR, use the command as follows:
mtr -rwbzc100 haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com

@andyli Using VPN can solve this problem, but most people do not have VPN.

I can’t seem to get useful information from here.

sudo /opt/homebrew/Cellar/mtr/0.95/sbin/mtr -rwbzc100 haxelib-tr40bgq5.fra1.cdn.digitaloceanspaces.com
Password:
Start: 2022-05-29T23:50:07+0800

All in all, very bad. :nauseated_face:

The mtr command takes a while to complete. For my machine it took several minute. Please try again and post the complete response.

@andyli Does this help?

Start: 2022-05-30T06:25:50+0800
HOST: MacBook-Pro.local             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.0.1                       0.0%   100    2.7   3.0   1.7   7.6   1.0
  2. AS???    192.168.1.1                       0.0%   100    3.1   3.4   2.2   8.0   1.0
  3. AS???    100.64.0.1                        0.0%   100   12.8   8.9   4.4  50.0   7.6
  4. AS4134   14.148.20.161                     0.0%   100    6.4   6.5   4.0  14.8   1.3
  5. AS4134   14.148.18.33                      0.0%   100    7.8   9.2   6.9  12.2   1.1
  6. AS4134   202.97.89.218                    85.0%   100   10.0  10.1   8.3  13.3   1.2
  7. AS4134   202.97.94.102                     0.0%   100   13.6  15.1   9.7  22.0   2.6
  8. AS4134   202.97.25.134                     0.0%   100  176.3 175.8 170.9 180.4   2.3
  9. AS4134   218.30.54.245                     0.0%   100  159.6 159.9 158.0 170.6   1.7
 10. AS33438  151.139.72.6                      0.0%   100  159.1 158.0 156.5 163.9   1.3
 11. AS20446  map2.hwcdn.net (205.185.216.42)   0.0%   100  165.2 165.9 163.5 171.9   1.2

Here is the reply from Digital Ocean:

After review, we’re able to identify loss occurring at the ChinaNet Backbone Network, carrying through to the final location. Unfortunately, we are unable to make changes to our network infrastructure meaning that we’re limited in the actions that we can take to alleviate this impact. What may best help is to reach out to your ISP, sharing the MTR reports with them as well to see if they’re able to provide a remedy at their end or an upstream endpoint.