HTTP request to dev Repl fails ("Unable to create HTTP connection::No route to host?")

[Griffin]

http.request in my current project fails to get the data served from my custom dev webserver which is hosted in a non-deployment dev environment.

The URL is accessible publicly and works in browsers (format: “uuid.picard.replit.dev/latestCommit” but with a full length uuid8 instead of “uuid”)

Despite being accessible in browsers and from cURL, Defold http.request doesn’t seem to be able to access it.

The specific error is:

ERROR:SCRIPT: Unable to create HTTP connection to 'https://cef0fd87-0f47-49e0-95a4-f9f20d3a59b0-00-28v4fhjrdk6ej.picard.replit.dev/latestCommit.txt'. No route to host?

(do note that if you try to manually access this url, it will only work while the repl is activated which is when I am working on it, otherwise the stable api url is used)

To produce yourself:
-Make free account on repl.it (just email, pw, username asked)

-Make a new Repl in any programming language of your choice and write a basic webserver (not default static content serving for HTML-specific repls, so all non-HTML template repls should reflect the same problem)

-Make the webserver serve content that is http code: 200, mimeType: “text/plain”, dataformat: utf8
-Open the web preview in replit

This will open a new tab with a temporary development url hosted in GCP. The URL is valid and accessible online until you exit the development environment tab (it is NOT a localhost server).

Trying to send http.request GET to this URL gives me the error I said before

Any and all insights appreciated! If anyone doesn’t want to go through the pain of making a server then DM me on any platform and I can arrange a time to host it for you.

[britzl]

@Griffin

and from cURL

Could you please run cURL with verbose flag on and share the output here. I’m sure there’s something in the output which will be helpful. Remember that http.request() is quite basic and might not respect certain response headers or other nuances of an http request and response.

[Griffin]

Hi björn!

Happy to curl it verbosely for you. Here is the output:

*   Trying 35.226.206.236:443...
* Connected to cef0fd87-0f47-49e0-95a4-f9f20d3a59b0-00-28v4fhjrdk6ej.picard.replit.dev (35.226.206.236) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.picard.replit.dev
*  start date: Jan 24 19:35:31 2024 GMT
*  expire date: Apr 23 19:35:30 2024 GMT
*  subjectAltName: host "cef0fd87-0f47-49e0-95a4-f9f20d3a59b0-00-28v4fhjrdk6ej.picard.replit.dev" matched cert's "*.picard.replit.dev"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.1
> GET /latestCommit HTTP/1.1
> Host: cef0fd87-0f47-49e0-95a4-f9f20d3a59b0-00-28v4fhjrdk6ej.picard.replit.dev
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Content-Type: text/plain
< Date: Fri, 02 Feb 2024 04:28:37 GMT
< Replit-Cluster: picard
< X-Robots-Tag: none, noindex, noarchive, nofollow, nositelinkssearchbox, noimageindex
< X-Robots-Tag: none, noindex, noarchive, nofollow, nositelinkssearchbox, noimageindex
< Transfer-Encoding: chunked
< 
* Connection #0 to host cef0fd87-0f47-49e0-95a4-f9f20d3a59b0-00-28v4fhjrdk6ej.picard.replit.dev left intact
661faac%                                                                                                                                                                      
~

[britzl]

I set up a Repl myself and was able to reproduce the issue, but I don’t know what is causing it. I don’t really see anything in the log. I bet it is something in either the dns lookup or the ssl handshake that is failing, but in order to figure it out I need to add a bunch of extra logging to the http client code in the engine, and I don’t have time to pursue this now. Sorry.