default of browser.serverAddress is not actually "localhost" about streamlit

[wyattscarpenter]

@raethlein interesting! I'm on Windows 10 (and the same thing happens in WSL on that machine). As far as I know I'm not in a VPN, VM, or container. I'm using streamlit 1.34.0 but it's been like this since I can remember. I can connect via localhost.

Looking at the method you cite, the cause is straightforward: I have server.headless set to true in the config as well. So the elif config.get_option("server.headless") triggers. Removing that makes my ouput

  Local URL: http://localhost:8501
  Network URL: http://10.150.8.250:8501

as well.

[raethlein]

Great!
Do you have a suggestion of how we could improve the docs to make this more clear or is it good as is then?

[vdonato]

Going to transfer this issue into the docs repo so that it's in a more correct location

(Huh, looks like I can't for some reason 😕)

[wyattscarpenter]

That seems like a pretty good solution to me.

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[raethlein]

Hey @wyattscarpenter, I have just tried to reproduce it on my M1 Mac, but there it behaves correctly and I correctly see

You can now view your Streamlit app in your browser.

Local URL: http://localhost:3000
Network URL: http://192.168.0.200:3000

The log lines seem to come from this method where also the IP address is determined; when no respective config options are set, it seems to jump into net_util.get_internal_ip() which seems to determine the IP address via the socket package for the log. The bound address itself should depend on tornado's listen method which we call here.

I don't have anything set in the config.toml file. Are you connected to a VPN or run the app in a virtual machine or container or so? And are you able to connect to the app via localhost despite the log showing a different address?

[wyattscarpenter]

I'm not sure whether or not it's a docs issue. I don't know why the server.headless setting overrides the browser.serverAddress setting. Maybe it's a good reason, since the behavior seems intentional. I could imagine that for some reason a headless server might need to output the things it currently does. But maybe not.

Assuming the behavior is desirable: add note (in both places?) that server.headless overrides the browser.serverAddress setting.

If the behavior isn't desirable: make it not do that, I suppose.

[raethlein]

good points, thanks 🙂 I guess the behavior is desirable since you can also connect via localhost and that the output prints are misleading. So looking at the lines I guess that localhost should be printed out additionally when the mode is headless.