[continuations]

- What are the advantages of using this over something more established such as Nginx or H2O?

- README mentioned "fully non-blocking architecture," this only refers to network IO, correct? My understanding is that Linux doesn't have truly non-blocking file IO. Is that right?

[bwindels]

The linux aio syscalls (io_submit, ...) work well on some filesystems (xfs, ext4, ...) but block on others (btrfs). It limits your file system choices but allows for a single threaded, concurrent web-server. This is what I ended up using for my hobby web-server wwwee [1] as low memory usage and good performance on a single core was an important constraint. It is sort of an opinionated design though.

1: https://github.com/bwindels/wwwee

[JdeBP]

... 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.

[mbien]

- Main advantage is simplicity, but architecture is in fact very similar to nginx. So, server should be faster than nginx but scale similarly. But it's all still highly DIY

- You're right, I mean non-blocking architecture of network IO.

[sigi45]

Lucky enough 'should be' is not a accepted benchmark ;)

Don't get me wrong, nginx is big and has more experience. Different headers, compression, security etc.

I would not even advice people using something like LEAR alone for the fact of undetected security issues.

[mbien]

I agree, I don't claim it's ready Please, treat it as interesting project to follow that has just started, and is surely not meant to be deployed in production environments, at least not in this state