http server configuration has wrong hostname and port if they are set through cli ( -H hostname -p port )

[Ventus218]

Describe the bug

It looks like that even if the application has been started setting custom hostname and port via CLI, the hostname and port properties of app.http.server.configuration return the default 127.0.0.1:8080.
Some other properties may be incorrect too, I didn't test those.

To Reproduce

Steps to reproduce the behavior:

1. Add a line to print hostname and port.

app.logger.log(level: .warning, "\(app.http.server.configuration.hostname):\(app.http.server.configuration.port)"

2. Run the application setting custom hostname and port.

vapor run serve --hostname 192.168.1.14 --port 8081

3. Output is

[ WARNING ] 127.0.0.1:8080
[ NOTICE ] Server starting on http://192.168.1.14:8081

Expected behavior

I think that configuration should reflect the real hostname and port that the server is running on.

[ WARNING ] 192.168.1.14:8081
[ NOTICE ] Server starting on http://192.168.1.14:8081

Environment

• Vapor Framework version: 4.54.0
• Vapor Toolbox version: 18.3.3
• OS version: macOS Monterey 12.1

Additional context

If hostname and port are changed programmatically in configure.swift configure method then they are successfully set to the correct values.

[0xTim]

The issue you're hitting is that you're attempting to print the hostname and port before Vapor has read the command line arguments. Vapor only reads these parameters when it starts ups which is after you call configure

[Ventus218]

The issue you're hitting is that you're attempting to print the hostname and port before Vapor has read the command line arguments. Vapor only reads these parameters when it starts ups which is after you call configure

I tried to log configuration hostname and port inside a route handler and the result is the same as I reported before.

/// 127.0.0.1
req.application.http.server.configuration.hostname

/// 8080
req.application.http.server.configuration.port

Did you actually try to see if you get the same behaviour as me?

[vzsg]

Your observation seems to be on spot, and I see something in the code that explains it.

These lines in HTTPServer.swift operate on a copy of the configuration, and the original self.configuration is not updated with the overridden values. Therefore, the app listens on the correct address/port, but req.application.http.server.configuration doesn't reflect that.

[Ventus218]

@vzsg Yes that is true, I looked at the code and to my surprise it seems like that has been done on purpose.
In Application+HTTP+Server.swift server is initialized, and it is inserted into the storage.

As you can see here (Application+HTTP+Server.swift) configuration cannot be changed after the server has been inserted into the storage.
So as soon as you call app.http.server you cannot actually update configuration anymore.

It looks like this was known and in fact, as you reported, the address' override is done on a copy which is used just to start the server and then is actually thrown away.

Unfortunately right now I have not enough knowledge of vapor to be able to make some good modification to fix this bug. Furthermore It doesn't look like a simple thing to do.

But still I would love to contribute to this amazing framework. Feel free to ask for any help :)

[0xTim]

Just put a PR up to fix this

[rkreutz]

Hey everyone, I've just faced this exact same issue recently, I'm using version 4.65.1 and it is still happening. I actually managed to find a couple fixes for it so I'll open some PRs shortly and then you guys could decide which approach is best. For reference you can easily reproduce the issue with the following simple project
vapor-config-test.zip
Just run vapor run serve --hostname 0.0.0.0 and call curl 0.0.0.0:8080 you'll get 127.0.0.1:8080 as the server's address

[0xTim]

@rkreutz 0.0.0.0 is not a valid hostname, that just says you should listen to connections from all IP addresses. The address is still 127.0.0.1 as you'll be making a request to http://127.0.0.1:8080/myPath right?

[rkreutz]

hey, so you can actually do curl 0.0.0.0:8080 and it should work, when you start the server it also says listening to http://0.0.0.0:8080, when I say the address is not updated is actually application.http.server.configuration.hostname which is not updated. You can as well use your local ip and the same would happen (server will listen to the right hostname but configuration.hostname is not updated)