I have a snap-based application that I'd like to have listen on a port other than 8000.
I create a custom config as follows:
myConfig = addListen (ListenHttp "0.0.0.0" 8080) emptyConfig
However, if I use this, I find that my app listens on both port 8000 and 8080. This is confusing and undesirable, and I don't understand why it's occurring or what to do about it.
Actually, it's a bit worse than I described. Not only can I not prevent a snap app from listening on port 8000, but suppose I explicitly set the default to 8000, like this:
myConfig = addListen (ListenHttp "0.0.0.0" 8000) emptyConfig
In this case, the app will try to listen twice on port 8000. Naturally, the second attempt will fail, so the app will exit immediately.
This means that not only can I not change the default port to something else, I cannot explicitly set the default to 8000, either. You might wonder why I'd try that: it's because I am using a config library to read config information from a file, and it's easiest to write that sort of code like this:
port <- C.lookupDefault 8000 cfg "server.port"
where if there isn't a value for server.port in the config file, the default value of 8000 is used instead.
And there's another bug related to this! Suppose I set the default to port 8001 as in my second comment above. If I want to change the port I listen on to something else on the command line, I'll want to use the -p option, but that will make my app listen on both 8001 and whatever port I specified with -p.
Clearly some of the config handling code is pretty messed up :-(
I don't disagree that the behavior is not correct, but for now it looks like if your app is based on the template or you are using the default command line config stuff, you should be able to just specify "-p 8080" on the command line to get the desired behavior of listening on only port 8080.
Yeah, if I comment out all my config code, I can get that behaviour ... but that's not what I want :-)
Understood. In the next few weeks we're going to be putting a lot of effort into the next release, so we should have something to address this soon.
Bryan, can you catch me on IRC sometime today to discuss this?
This should be fixed as of 0.5.0. Please reopen if it's still insane.