darkhttpd is cool, and it's pretty featureful for a small program, but it's also 2500 lines of code.

If you liked it, you might also like my server httpdito: http://canonical.org/~kragen/sw/dev3/server.s which has documentation in http://canonical.org/~kragen/sw/dev3/httpdito-readme. It's also an HTTP server in a single source file, but it's i386 assembly, for Linux, that doesn't use libc. It's only about 700 lines of code, and the executable is up to 2060 bytes now that I've added CSS and PDF support to it.

httpdito is, to my surprise, practically useful on occasion as an alternative to things like `python -m SimpleHTTPServer`.

Unlike the server in Koshkin's excellent comment https://news.ycombinator.com/item?id=26672683 httpdito does send CRLFs as the HTTP standard demands. Unfortunately it also requires them in the request. Also—and this is a key point on which most software falls down—httpdito's documentation contains a section entitled "Are you insane?", which really is a question every programmer ought to answer in their documentation.

It doesn't have most of the things darkhttpd has, though. It doesn't support IPv6, HEAD, directory listings, byte ranges, conditional requests, keepalive, name-based virtual hosting, sendfile, logging, chroot, or privsep, and doesn't run on Solaris, SPARC, or ARM. But if you're looking for features like "small memory footprint" and "no installation needed" and "no messing around with config files" it may actually be better than darkhttpd. Due in large part to improvements in modern Linux and its small memory footprint (normally 5 pages) it's efficient enough to saturate a gigabit connection.

It’s funny, this is the exact kind of thing I’d want on a non-x86 system. Raspberry Pico for example would be a great place for a 2KB HTTP server but with not support for HTTPS, IPv6, or for any non-x86 architectures it’s a bit of a non-starter for my use cases. Still, very cool project!

The CPU architecture is actually the least of your concerns there—I'm pretty sure qemu-user can run httpdito on ARM with less than an order of magnitude performance overhead. There are a lot of embedded systems where an HTTP transaction per second per MHz would be more than sufficient.

The bigger problem is that the Raspberry Pico is a dual-core Cortex-M0+, which doesn't have an MMU, so it can't run Linux and especially can't handle fork(). But httpdito is basically scripting the Linux system call interface in assembly language—it needs to run on top of a filesystem, an implementation of multitasking that provides allocation of different memory to different tasks, and a TCP/IP stack. Any one of these is probably a larger amount of complexity than the 296 CPU instructions in httpdito.

The smallest TCP/IP stack I know of is Adam Dunkels's uIP. Running `sloccount .` in uip/uip cloned from https://github.com/adamdunkels/uip gives a count of 2796 lines of source code ("generated using David A. Wheeler's 'SLOCCount'."). uIP can run successfully on systems with as little as 2KiB of RAM, as long as you have somewhere else to put the code, but for most uses lwIP is a better choice; it minimally needs 10KiB or so. uIP is part of Dunkels's Contiki, which includes a fairly full-featured web server and a somewhat less-full-featured browser. I think he got both the server and the browser to run in 16KiB of RAM on a Commodore PET, but not at the same time.

(twIP http://dunkels.com/adam/twip.html is only 139 bytes of C source but doesn't support TCP or any physical-layer protocol such as Ethernet, PPP,or SLIP.)

However, Adam Dunkels has also written Miniweb http://dunkels.com/adam/miniweb/, which implements HTTP and enough of TCP and IP to support it, in 400 lines of C. It needs at least 30 bytes of RAM. Like twIP, it doesn't provide a physical layer. But that's solvable.

Not having MMU means there's no virtual memory and instructions refer to physical memory addresses, cmiiw?

You say Linux won't work without MMU, it can't handle physical addresses? Moreover, why won't fork() work without MMU?

Without an MMU, you can't do paging. That means fork() cannot do the normal copy-on-write business, because there's no page table to copy the entries in.

You also have no inter-process security, so everything can crash everything else including the kernel, and no swap.

It used to be the case that all Linux executables had to be loaded at the same virtual address, but ASLR may have removed requirements of this kind. https://stackoverflow.com/questions/38549972/why-elf-executa...

Maybe you mean that before ELF support, Linux a.out executables had to be loaded at a fixed virtual address? That's possible—I started using Linux daily in 01995, at which point a.out was already only supported for backward compatibility.