Associate executables with extensions

[joewalnes]

At the moment, websocketd will map urls to files and then attempt to execute the file itself.

It would also be useful to allow the file to be executed by another program. This mapping will be done by file extension.

This removes the need to have a #!/usr/bin/blah header at the top of each script.

Examples of when this is useful:

• PHP: Typically PHP files do not include the #! header and are identified by a .php extension.
• Windows scripting host: Avoids the needs for a .cmd file for each script.

Implementation notes:

• Should be possible to define executors for more than one file extension.
• Should be possible to specify additional cmd line args that can be passes to executable.
• Special care needed on case insensitive file systems to ensure correct executable still gets invoked (e.g. foo.PhP)

[asergeyev]

Do you think it slightly leads to some kind of config file for websocketd?

Things are getting more and more complex. Right now you have simplicity of inetd and dealing with needs to go to something like xinetd :) I wonder where you think it should stop.

Making a config file will ultimately lead to creating flexible solution. But there will be always users who manage to mess things up :) Creating simple solution is another option but not every case will be handled by it.

IMO simple would be to create "--exec=script" flag and make people to use their own scripts to handle/exec correct command based on URI in directory... If current directory does not have runner, it'll look level up, stopping at websocket root dir (similar to how .htaccess or .git are getting searched). Then if you have php scripts, you put runner with something like

$!/bin/sh
exec /usr/bin/php $(basename $0)

IMO your server should be gearing towards "simple". Flexible is for people who know what they are doing and should think about performance and/or resource management. Forking small scripts all the time is not something that they should be using.

[joewalnes]

It's a dilemma I've been wrestling with too.

A config file is separate issue. A few users have requested a config file instead of cmd line args and I see the benefit. If websocketd does support config files I would like it to be an alternative to the cmd line options - users may use whichever they prefer and all features are available to both.

I like the idea of having a single --exec=script that sits between websocketd and the final executable. This gives users the options of scripting up advanced rules in a single place in whatever language they like (e.g. url routers, diagnostic tools, authentication mechanisms, etc). websocketd remains simple and user scripts can be as flexible or as inflexible as they like.

[michaelmior]

It seems like the shebang is the way to go here. While it's true that PHP scripts do not typically include this, most PHP scripts are also not designed to be executed directly. For those that are, I think including the shebang makes sense. I know nothing about Windows Script Host however.

Anyway, it seems like if websocketd had this option, then there would need to be a way of configuring this for when it inevitably doesn't do what is expected or the user needs to specify a different binary. But the easiest way to do configuration is just to have the shebang line.

[asergeyev]

I wonder why nobody ever were asking this... I'd close in few months if it's quiet.