Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Nginx
An official read-only mirror of http://hg.nginx.org/nginx/ which is updated hourly. Pull requests on GitHub cannot be accepted and will be automatically closed. The proper way to submit changes to nginx is via the nginx development mailing list, see http://nginx.org/en/docs/contributing_changes.html
-
http
A simple multi-threaded HTTP/1.0-ish file server. Single file, ~250 LOC. (by pablo-mayrgundter)
Better link since submitted one appears down https://github.com/emikulic/darkhttpd
One of 2004 IOCCC winners (2004/hibachi [1]) was a CGI and vhost capable HTTP server. It is one of a few winning entries that ever came with its own ./configure, and violated so many guidelines but not a single rule, making judges pretty upset.
[1] https://github.com/ioccc-src/winner/blob/main/2004/hibachi.h...
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.
In 7000 lines I add multi-threading, non-blocking IO, dynamic responses, chunking and hot-deployment:
https://github.com/tinspin/rupy
>so you can't run a chat server on them
https://github.com/agarrharr/awesome-static-website-services...
I can see you've spent a lot of time thinking about things like slowloris. What do you think of the approach that redbean takes? https://justine.lol/redbean/index.html It still needs more unit tests, but basically what it has is a meltdown mode so that when fork() starts to fail it sends SIGUSR2 to the process group to EINTR recv() calls so that lingering processes can exit gracefully. Its parser also isn't cubic, so even for a fragmented messages, it only needs to consider each character a single time: https://github.com/jart/cosmopolitan/blob/master/net/http/pa...
I'm pretty sure Linux ELF has always allowed you to specify the initial load address. When I first wrote StoneKnifeForth https://github.com/kragen/stoneknifeforth its load address was 0x1000, but at some point Linux stopped allowing load addresses lower than 0x10000 by default (vm.mmap_min_addr). I originally wrote it in 02008, using the lower load address, and fixed it in 02017. It's still not using 0x804800 like normal executables but 0x20000. ASLR does not affect this.
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.
It wasn't obfuscated at all. The guideline doesn't explicitly dislike such entries, but as a side effect it implicitly violated several guidelines at once (e.g. it was quite "longer than [it] need[s] to be"). Indeed, today's nginx source code [1] would be probably slightly more obfuscated than this code modulo perhaps name changes (that can be considered as a minimal effort to get the entry within the size limit).
[1] for example, https://github.com/nginx/nginx/blob/8365f73/src/http/ngx_htt...
My single file HTTP/1.0-ish java http server:
https://github.com/pablo-mayrgundter/http
I use it for most of my local dev. Handles only GET requests, serving files below the directory in which the server is started. Does Content-Type inference based on file extensions (e.g. html, js, png, jpg).
Currently disables any type of cacheing as I use it mostly for local development and want to avoid versioning mistakes.
Also has fledgling SSL support that has occasionally worked.
> ./http_load -p 10 -f 100000 test.url