| ... or indeed publicfile. * http://cr.yp.to/publicfile.html * http://jdebp.eu./Softwares/djbwares/guide/httpd.html * http://jdebp.eu./Softwares/nosh/guide/tcp-socket-accept.html Some of the lessons not learned from publicfile by this include: * It entirely lacks doco, having zero manual pages or even --help text. I strongly encourage remedying this as soon as possible. Start as you mean to go on, with decent user doco right from the beginning. Instil a culture of keeping the doco up to date as the program changes, and rejecting changes that do not keep the doco in synch. * It uses a single logfile, with unbounded growth, potentially with superuser privileges, and yet another idiosyncratic logfile configuration mechanism. Just write to standard error and let the system's service/logging management take care of things. daemontools family systems will run it through multilog, cyclog, or similar. systemd will run it through systemd-journald. Both will do the proper rotation by the writer; and daemontools family loggers will even (conventionally) use unprivileged logging processes that cannot eat into the superuser-reserved emergency disc space. * There is very poor error handling and recovery in some places. A particularly noteworthy example is that if the master cannot fork enough worker processes, which does happen in real life, it carries on regardless and erroneously falls into the child process code. M. Bernstein's approach was to error check everything, from out of memory conditions in string concatenations to the result of chdir(). * There's no protection at all against malicious client requests. Do not think that a server being read-only is enough. publicfile documents (q.v.) what it does to stop requests escaping the data directory root, to stop upwards directory traversals, and to avoid things like attempts to read from non-regular files. * There's not even rudimentary virtual hosting. There are a few other problems with this, such as the amount of static configuration information that is needlessly re-decoded on every read(), the laborious string handling and head-body parsing, and the faulty implementation of HTTP/1.1; but those aren't direct cases of not learning the fundamentals from existing static-content-servers as the aforementioned are. |