Request: Configuration file

[xPh03n1x]

I've been using Websocketd for some time now and its a really useful tool. However, when there are multiple instances of websocketd on a development server, utilized by multiple people for various purposes, it becomes a real nuisance to take care of the machine in the event of an accident when there are multiple processes using 10+ parameters in their command line, expanding over 3+ lines in a process list.

Generally I believe it would be quite easier for websocketd users as well if the settings were defined in a standalone config file, rather than passed as arguments. If this was C, Python, PHP, or Bash I would've spent the couple of hours needed to expand the functionality of config.go and filed a PR, but given that websocketd is based on Go, at which I am not fluent, I'd prefer to leave that to the professionals - you guys.

I hope you understand my point and you will agree with me that passing settings as 10+ script parameters is easier and quicker to do for a prototype, but for the long run - its just unprofessional. A config file is the better approach and I do believe that you have reached the point to integrate this given the age of websocketd.

[asergeyev]

I don't mind a conf file...

Could you propose format for it so others could weight in here?

I just think command line flags would stay and have precedence anyway.

[xPh03n1x]

Thank you for the reply.

I didn't mean to imply to replace command line parameters as a whole, just implement a way for a config file to be used instead. In turn that would render far shorter line in the process list.

The config file can have a single general location, acceptable across a variety of distros, like /etc/websocketd.conf with settings formatted in a similar fashion to:

[Network]
#interface to bind to
address=127.0.0.1

#port to listen for connections
port=443

#HTTP port to redirect to canonical `port` address
redirport=8443


[SSL]
#Whether to use SSL encryption
ssl=false

#path to SSL certificate in PEM format, when ssl=true
sslcert=/tmp/domain.ssl

#path to SSL private key, when ssl=true
sslkey=/tmp/domain.rsa


[Headers]
#custom headers for any response
header='websocketd server'

#custom headers for all but WebSocket upgrade HTTP
header-http='websocketd server'

#custom headers for successful WebSocket upgrade
header-ws='websocketd server'


[Operational]
#Log level, one of: debug, trace, access, info, error, fatal (default "access")
loglevel=access

#Restrict upgrades if origin does not match the list
origin='127.0.0.1:443'

#Whether or not to restrict WebSocket upgrades if the origin and host headers differ
sameorigin=true

#Use experimental binary mode
binary=false

#Time to start sending signals (0 never)
closems=100

#Max forks the server can spawn. 0 is unlimited
maxforks=0

#List of envvars to pass to subprocesses
passenv="PATH,DYLD_LIBRARY_PATH"

#Perform reverse DNS lookups on connecting remote clients
reverselookup=false


[Server]
#Directory base for WebSocket scripts
dir='/full/path/to/WebSocket/scripts'

#Serve CGI scripts from this directory over HTTP
cgidir='/full/path/to/cgi/dir'

#Serve static content from this directory over HTTP
staticdir='/full/path/to/static/content/dir'


[Other]
#Console for development purposes (cannot be used in conjunction with staticdir)
devconsole=true

The grouping of course would be just for ease of use to people new to websocketd. The names for the settings can be retained to keep a general namespace, allowing easier future code moderation when it comes to manipulating supported options.

A config without any comments or groups would be even smaller:

address=127.0.0.1
port=443
redirport=8443
ssl=false
sslcert=/tmp/domain.ssl
sslkey=/tmp/domain.rsa
header='websocketd server'
header-http='websocketd server'
header-ws='websocketd server'
loglevel=access
origin='127.0.0.1:443'
sameorigin=true
binary=false
closems=100
maxforks=0
passenv="PATH,DYLD_LIBRARY_PATH"
reverselookup=false
dir='/full/path/to/WebSocket/scripts'
cgidir='/full/path/to/cgi/dir'
staticdir='/full/path/to/static/content/dir'
devconsole=true

Furthermore, the relation to a config file can be set with just one parameter like --config='/path/to/config' and then in turn utilize the settings from that file, essentially allowing people to have multiple websocketd instances running on a single machine, each using a separate config file.

[asergeyev]

I think I like idea of config (2) where flags just listed with values... And IMO quotes should be optional here... as semi-interesting outcome we may do comments allowed in all ways

[something]
; something
# something

would be just ignored on parsing (not sure if # comment should be allowed after value, I tend to say "no")

I'll probably take on this in few days unless someone else has more time for it :)

[asergeyev]

We will probably have

--config filename

to read that config values as "defaults" for flags. Any flag given would override the config (as it now overrides defaults)

[leolivier]

Hi @asergeyev any news about that? (If I may, I think yaml or json would be a better move than windows ini file like format, much easier to get it flexible at several levels)