remove remnats tentacles of the executor process

remove unused entrypoint field ventige of the cgi support (and lack of url rewriting)

drop cgi vestiges from the struct host The `env' list is no longer used since CGI scripts were removed

retire the deprecated `mime' and `map' config options

make the mime types fixed-sized too

make config fields `chroot' and `user' fixed-size

optionally disable the sandbox on some systems The FreeBSD and Linux' sandbox can't deal with `fastcgi' and `proxy' configuration rules: new sockets needs to be opened and it's either impossible (the former) or a huge pain in the arse (the latter). The sandbox is still always used in case only static files are served.

gc FILE_EXECUTABLE

gc sandbox_executor_process

get rid of the CGI support I really want to get rid of the `executor' process hack for CGI scripts and its escalation to allow fastcgi and proxying to work on non-OpenBSD. This drops the CGI support and the `executor' process entirely and is the first step towards gmid 2.0. It also allows to have more secure defaults. On non-OpenBSD systems this means that the sandbox will be deactivated as soon as fastcgi or proxying are used: you can't open sockets under FreeBSD' capsicum(4) and I don't want to go thru the pain of making it work under linux' seccomp/landlock. Patches are always welcome however. For folks using CGI scripts (hey, I'm one of you!) not all hope is lost: fcgiwrap or OpenBSD' slowcgi(8) are ways to run CGI scripts as they were FastCGI applications. fixes for the documentation and to the non-OpenBSD sandboxes will follow.

encode file names in the directory index Spotted the hard way by cage

sort the MIME mappings and do a binary search to match

don't load the built-in list when using `types'

allow add_mime to fail add_mime nows allocate dinamically copies of the passed strings, so that we can actually free what we parse from the config file. This matters a lot especially with lengthy `types' block: strings that reach the internal mapping are never free'd, so every manual addition is leaked.

fix an out-of-bound access in start_cgi Long time ago, client->req was a static buffer so the memcpy was safe. However, it's been since moved to a dynamically allocated string, so it's very often smaller than sizeof(req.buf) (1024), hence the out of bound access which results in a SIGSEGV very often on OpenBSD thanks to Otto' malloc. The situation with the iri parser, client->req and how the request is forwarded to the other process needs to be improved: this is just a fix to address the issue quickly, a better one would be to restructure the iri parser APIs and rethink how the info is forwarded to the ex process.