nonLocal took too long to respond

[danielbogomazov]

I've copy and pasted your example App.tsx into my project to start out with. It seems to be working as expected inside the WebView in the app running locally on my Android device.

The issue I'm having is trying to connect to the server from my desktop (same network). I've passed in nonLocal: true into the constructor to allow for non-local connections but whenever I try to connect to it, my desktop's web browser returns with a ERR_CONNECTION_TIMED_OUT page (which seems to imply that it's able to find the server but not able to establish a connection?).

I've tried this with v0.8.0, v0.7.13, and v0.7.12 - none fix this issue.
The only error I get is from lighttpd (pulled from Android Studio):

2023-07-21 10:26:19.822 12214-15837 lighttpd com.storystream E (C:/Users/....../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)

Looking at that line in the linked library, it doesn't seem like it's an actual error, just there for logging purposes (I think?).

Here's what I see in metro:

LOG Server #41691.
Origin: New state: "STARTING".
Details: "".
LOG Server #41691.
Origin: http://10.0.0.251:41643 New state: "ACTIVE".
Details: "".
Done in 946.53s.

Opening the origin on my Desktop times out.

• Developing on Windows
• Running on Android
• react v18.2.0
• react-native v0.72.0

[birdofpreyru]

Looking at that line in the linked library, it doesn't seem like it's an actual error, just there for logging purposes (I think?)

Correct, it just logs as "errors" both regular log messages, and actual errors.

From what you say you see in the logs, it seems the server has started fine... probably the firewall on your machine blocks the connection?

[danielbogomazov]

Doesn't seem to be a firewall issue. I've turned it off on my machine and it still won't connect. I tried connecting using my phone on the network but no luck there either.

I turned on all error logging flags to see if I could find any hint as to what's happening. This was what I found in ERROR_LOG_FILE after trying and failing to connect to the server a couple times:

2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)
2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-ssl-noise (ignored)
2023-07-21 12:45:36: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1224) [note] graceful shutdown started
2023-07-21 12:45:36: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.2336) server stopped by UID = 0 PID = 0
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-ssl-noise (ignored)

Only thing that pops out is the "unknown config-key" error. I tried to take a look at the lighttpd1.4 file where this error was logged but it's not immediately obvious to me as to what's actually happening there.

[birdofpreyru]

Hmm… looks like there is smith messed up with logging config… though it should not cause troubles you experience. For me it looks like the server is running fine, but for some reason your requests do not arrive to the server, and just do get lost somewhere 🤷‍♂️

I’ll double check next week if non-local mode works for me in the example app.

[birdofpreyru]

Actually, it probably just starts on a wrong network interface, try to use ‘hostname’ argument to explicitly specify the IP of device on your local network.

[danielbogomazov]

Adding the hostname did not solve it.

I deleted my app and reinstalled it through Android Studio and now it seems to be working. Maybe something with hot reloading the app over and over again broke something?

I try to hot reload the app while developing. If the library yells at me that there's already a server running after hot reloading, I quit out of metro and restart. I think the hot reload bug that I was facing is referenced in this issue - but it's not consistent for me. When I reload metro, I'm able to start a new server again.

The fix resulting from uninstalling the app leads me to believe that it could have been caused by the server leaking someway, somehow - but I have no idea how lighttpd works so this is a complete guess.

I'll keep an eye out to see if I can spot any way to reproduce this consistently if I run into it again.

[gstrauss]

debug.log-ssl-noise is recognized by lighttpd when a lighttpd TLS module is loaded. If one is not loaded, debug.log-ssl-noise is an unknown config-key

debug.log-condition-cache-handling is not a lighttpd config directive (unless @birdofpreyru patched this in). The upstream lighttpd config has debug.log-condition-handling, which is spelled differently.

@birdofpreyru Regarding #56, why not use a mutex to ensure that only one thread is starting and stopping lighttpd before releasing the mutex for another thread to do so?

[birdofpreyru]

Hi @gstrauss , thanks for passing-by to comment on this! :)

Re. debug.log-condition-cache-handling, I actually just got it from Lighttpd Wiki: https://redmine.lighttpd.net/projects/lighttpd/wiki/DebugVariables

Re. #56 — It was my mistake — I did a similar thing in JS layer from the very beginning, but I haven't thought about advanced scenarios where React Native can re-load my JS module, destroying my synchronization of methods on JS side. Thus, it indeed needed synchronization of threads in the native layer, and presumably I've nailed it now.

[birdofpreyru]

@danielbogomazov Regarding your original complain, I finally tried to reproduce your scenario with the Example app, and it worked for me without any issues:

• I used a real Android device. Connected it to my machine and did

  $ adb shell ip addr

  to find out its IP address (say 111.111.111.111) on my WiFi network.
• Then in the Example app I just added hostname and port (just to simplify the test, I guess, the auto-selected port should work just fine as well) to the Server options on this line:

  react-native-static-server/example/src/App.tsx

  Line 53 in 7a58473

  let server: null | Server = new Server({ fileDir, stopInBackground: true });

  
  turning it into

  let server: null | Server = new Server({
    fileDir,
    hostname: '111.111.111.111',
    port: 3000,
    stopInBackground: true,
  }); 

• Then just deployed & run the app on the device, and I could see the test page both in the app on the device, and also by accessing 111.111.111.111:3000 in the browser on my desktop (and here I sure used a new incognito tab, as non-incognito tabs in Chrome have a habit to force connections to automatically force HTTPS connection, and HTTPS is not currently configured by this library).

Thus, I believe no issue here, I'll close this thread later.

P.S.: There is also a related open issue #21, saying that we need to add into the library some features to make it easier to list all connected network interface, or automatically select the interface needed for a particular purpose. The hostname option allowing to specify the IP to start on is a part of the solution, but beyond that resolving that issue is not on top of my priorities at the moment.

[gstrauss]

slightly off-topic: Re: debug.log-condition-cache-handling
There is no history of debug.log-condition-cache-handling in lighttpd git, other than imported invalid doc in the defunct 1.5.x branch, so I updated the wiki to remove debug.log-condition-cache-handling. Thanks for pointing it out.

/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
The directive is not recognized by lighttpd and does not do anything, so you probably should remove debug.log-condition-cache-handling from the config you provide.

[birdofpreyru]

Thanks for confirming @gstrauss 👍