An HTTP server in a single .c file

by egorfine • 5 years ago

283 98 5 years ago

rualca3• 5 years ago

I was about to submit this very link after reading this HN submission:

This blog is now hosted on a GPS/LTE modem (Apr 1, 2021) https://news.ycombinator.com/item?id=26669749

So darkhttp is a terribly simple HTTPS server that only supports GET and OPTION but is more than enough to serve static content.

kragen16• 5 years ago

darkhttpd supports HEAD too!

spzb• 5 years ago

Better link since submitted one appears down https://github.com/emikulic/darkhttpd

zoomablemind• 5 years ago

althttpd is another single-binary webserver [1]. It's from the creator of SQLite. Also single-binary Fossil SCM, by the same author, internally implements a webserver (which is multiplatform, by the way)

[1] https://sqlite.org/althttpd/doc/trunk/althttpd.md

silasdb• 5 years ago

I'm using it as well and it is great. The well designed approach to virtual hosts and CGI is relly awesome. Zero configuration needed.

indigodaddy• 5 years ago

Very cool! It talks about using stunnel for https, but for ssl termination I could just as easily put caddy or haproxy in front of the standard (non-https) http althttpd right?

lifthrasiir2• 5 years ago

One of 2004 IOCCC winners (2004/hibachi [1]) was an 154 line long CGI and vhost capable HTTP server [2]. 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. Its obfuscation was pretty basic even at that time and it won solely out of the novelty factor.

[1] https://github.com/ioccc-src/winner/blob/main/2004/hibachi.h...

[2] https://github.com/ioccc-src/winner/blob/main/2004/hibachi.t... (yes, it is also probably the only winning entry that its source code is packaged into a tarball.)

13of40• 5 years ago

I wish I could dig it up now, but years ago I ran a QA team that needed to validate that our equivalent of man pages could be downloaded on the fly with a command. The guy who owned it came up with a test plan that included setting up and maintaining a web server just for this purpose, and was dragging the project on for weeks until I sat through lunch one day and wrote him a bare bones HTTP server in Powershell that we could just start locally and talk to at run-time. I'm pretty sure the first cut of it was only like 50 lines of code.

majkinetor• 5 years ago

Today you can do it in single line.

aflag• 5 years ago

What is the sort of guidelines it violated?

lifthrasiir2• 5 years ago

It wasn't obfuscated at all. The guideline doesn't explicitly dislike such entries, but as a side effect of not being obfuscated 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 (and that can be considered as a minimal effort to get the entry within the size limit). Its only obfuscation was reusing a buffer from getenv() pre-initialized (referred as to "getenv() == "putenv()" in the hint).

[1] for example, https://github.com/nginx/nginx/blob/8365f73/src/http/ngx_htt...

imwally• 5 years ago

I'm not being snarky, but is a "single .c file" a good metric? It could be a rather large single file, right?

kzrdude• 5 years ago

It could be sqlite or a lua interpreter, yes.

rualca3• 5 years ago

I agree, jamming a program in a single source file is not the best metric ever.

To be fair, that's just a line in the project's Readme, which is far from the best and doesn't even provide a concise description of what the project does.

avhon1• 5 years ago

Being in a single .c or .h file does make a project easy to incorporate into the source tree of other projects.

Koshkin• 5 years ago

Here's one, small enough to fit in a comment:

  #include <stdio.h>
  #include <sys/types.h>
  #include <sys/socket.h>
  #include <netinet/in.h>

  main()
  {
        int rc;
        struct sockaddr_in ssa, csa;
        int ss, cs;

        memset(&ssa, 0, sizeof ssa);
        ssa.sin_family = PF_INET;
        ssa.sin_port = htons(8080);
        ssa.sin_addr.s_addr = htonl(INADDR_ANY);

        ss = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
        bind(ss, (struct sockaddr*)&ssa, sizeof ssa);
        listen(ss, 5);

        for (;;) {
                int ln;
                static char rq[1000];
                memset(&csa, 0, sizeof csa);
                ln = sizeof(struct sockaddr);
                cs = accept(ss, (struct sockaddr*)&csa, &ln);
                memset(rq, 0, sizeof rq);
                recv(cs, rq, sizeof rq, 0);
               
                if (!strncmp(rq, "GET /", 5)) {
                        char *b;
                        FILE *f;
                        char *fn;
                        if (b = strchr(rq + 5, ' ')) *b = 0;
                        else rq[sizeof rq - 1] = 0;
                        if (fn = malloc(strlen(rq + 5) + 5)) {
                            char *t, *type();
                            strcpy(fn, "www/");
                            strcat(fn, rq + 5);
                            if ((t = type(fn)) && (f = fopen(fn, "rt"))) {
                                 int n;
                                 static char h[] = "HTTP/1.1 200 OK\nContent-Type: ";
                                 static char c[1000];
                                 strcpy(c, h);
                                 strcat(c, t);
                                 strcat(c, "\n\n");
                                 sendall(cs, c, strlen(c));
                                 while ((n = fread(c, 1, sizeof c, f)) > 0) sendall(cs, c, n);
                                 fclose(f);
                            }
                            else {
                                 static char h[] = "HTTP/1.1 404 NotFound\nContent-Type: text/html\n\n404 Nice try!";
                                 sendall(cs, h, sizeof h - 1);
                         }
                         free(fn);
                        }
                }
                close(cs);
        }
       
        close(ss);
        return 0;
  }

  sendall(s, c, n)
  char *c;
  {
        int m; for (m = 0; (m += send(s, c + m, n - m, 0)) < n;);
  }

  char *type(fn)
  char *fn;
  {
      static char *s[] = {
          ".html", "text/html",
          ".asm", "text/plain",
          ".c", "text/plain",
          ".py", "text/plain" };
      int i;
      for (i = 0; i < sizeof s / sizeof *s; i += 2)
          if (strstr(fn, s[i]))
              return s[i + 1];
      return 0;
  }

vstm• 5 years ago

I find your lack of carriage returns disturbing

joshuaissac• 5 years ago

Context: RFC 2616 and RFC 7230 require CRLF line endings instead of just LF.

1. https://tools.ietf.org/html/rfc2616

2. https://tools.ietf.org/html/rfc7230

deathanatos2• 5 years ago

It's a simple server, yes, but it fails to correctly implement HTTP. But that's the trouble with all these "look a 'simple' X in N Loc"; yes, a great many things get simpler when you ignore the requirements of the standard.

It also has what I would call some security issues, e.g., you can ask for a file outside of the www directory.

Hydraulix989• 5 years ago

you can ask for a file outside of the www directory.

Was going to point that out, but you beat me to it.

_wldu• 5 years ago

Here's an HTTP server in one line of bash:

https://www.go350.com/posts/finding-a-hacked-server/#a-quick...

iod2• 5 years ago

Here is an HTTPS server in one line of posix shell and openssl¹ which also works as an alternative to `python -m SimpleHTTPServer`:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-384 -sha512 -subj /CN=localhost -keyout - -out - -nodes -addext subjectAltName=IP:::,IP:::1,IP:0.0.0.0,IP:127.0.0.1|openssl s_server -accept 8443 -WWW -no_ssl3 -no_tls1 -no_tls1_1 -cert -

I put this into https.sh marked executable and run anywhere.

¹ https://www.openssl.org/docs/man1.1.1/man1/openssl-s_server....

SavantIdiot• 5 years ago

Sigh. Yes, ANYTHING can be one line... if you're allowed to call tens of thousands of lines of code compiled in a different library.

It really defeats the purpose of showing off minimal coding skill if hundreds of other developers did all the heavy lifting over three decades.

cle• 5 years ago

I stuck that in /usr/bin/s, and now I present to you an HTTPS server in one character:

nepthar• 5 years ago

I think that’s a right of passage! https://twitter.com/nepthar/status/1324812161479311360?s=20

tyingq• 5 years ago

Here's a really terrible webserver as a "one-long-liner" in gawk. I was initially surprised to find that gawk could listen on a socket, so I made this monstrosity. https://gist.github.com/willurd/5720255#gistcomment-3143007

kragen16• 5 years ago

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.

mysterydip2• 5 years ago

Do you have plans for any of those features, or is it complete for the use cases it is solving?

kragen16• 5 years ago

No, I didn't write it to solve use cases at all, but rather because I thought it would be awesome to write a web server in assembly. As the readme says, we all have moments where we do things we regret. Youthful† lapses in judgment.

If you git clone http://canonical.org/~kragen/sw/dev3/.git you will see that I wrote most of it one weekend in 02013, removed the dependency on libc and added forking the next weekend, and tweaked it slightly over the next month and a half. Then in 02019 I added CSS and PDF to the mime-types list. So it's not, like, an ongoing project. It's just a program I wrote once, like most things in that directory.

I did just fix the documentation, though, because it was still claiming it was under 2000 bytes.

______

† Technically 37 is not actually that youthful.

colejohnson66• 5 years ago

For your website, it seems the files aren’t being encoded right because Firefox on iOS is rendering them as something else. I’m getting mojibake with apostrophes and the like:

### setup_socket: thereâ€™s little interesting to say here thatâ€™s not ### in, say, Beejâ€™s Socket Guide.

kragen16• 5 years ago

Thanks! Yeah, what happened was that Apache wasn't sending a content-type header until I tweaked the .htaccess file, which was about 14 minutes before you posted your comment. I had to ctrl-shift-r in Firefox to get it to notice the changed content-type.

IgorPartola• 5 years ago

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!

kragen16• 5 years ago

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.

fulafel• 5 years ago

Nice. Have you considered publishing it under a FOSS license?

kragen16• 5 years ago

Thanks. I thought I'd done so when I wrote it in 02013! I've now corrected the omission by adding a Creative Commons Public Domain dedication. Thank you for pointing that out!

Twirrim• 5 years ago

https://github.com/avleen/bashttpd for a bash based one (that uses socat or netcat under the covers)

runawaybottle• 5 years ago

What are the performance implications of something like this (and other similar ones posted here) for a really light server (let’s say a small chat server). Would getting down closer to the metal matter much?

jeffbee• 5 years ago

The performance problems of HTTP servers are architectural, not usually about things like instructions per cycle. For example common topics are whether accepting connections will tend to starve serving established connections, whether events are distributed optimally among threads or CPUs, how the server behaves if a client sends one byte per frame, very slowly, or if the client receives the response very slowly, whether the process will run out of memory if a number of events happen suddenly, etc. A web server that's actually equipped to survive as a public service will be much, much longer than 2500 lines of code.

kragen16• 5 years ago

While mostly I agree with your comment, I suspect both darkhttpd and httpdito (linked above) are actually equipped to survive as a public service. httpdito is about 700 lines of code (in assembly); it handles these issues as follows:

1. Accepting connections starving established connections: this is mostly a problem for event-driven servers. httpdito runs each connection in its own child process, has a compiled-in limit of 2048 concurrent connections. Whenever it has 2048 live children, it blocks in waitpid() until at least one of them dies. Modern Linux does a fair enough job of scheduling that this seems to be sufficient in practice to keep the parent from hogging the whole machine and preventing the children from making progress, even if most of your incoming connections just close without sending an HTTP request or any bytes at all. Darkhttpd might have a problem with this or not, I haven't tried, but it seems to rely on OS ulimits to limit its number of concurrent connections. My guess is that with the default ulimit -n 1024 darkhttpd won't have any problem with this at all.

2. Whether events are distributed optimally among threads or CPUs: the real issue here is not optimality but stability, and again, this is mostly an issue for event-driven servers (or servers made of thread pools, etc.) The essential property for production is usually not that you're using the machine to within 0.1% or 10% of its capacity, but that you're not wasting 99+% of its capacity uselessly thrashing—or, at the other extreme, responding so fairly that you provide some service to every client, but not enough to actually ever complete a whole request successfully. Modern Linux does a good enough job of this that httpdito's very stupid approach of forking a new child for each request works reasonably well. darkhttpd avoids the problem in a different way by not having threads and not using multiple CPUs, which is clearly not optimal but also totally avoids any related stability concerns.

3. How the server behaves if a client sends one byte per frame, very slowly: in overload conditions, which is when this matters "to survive as a public service", Linux's TCP stack does a reasonably efficient job of consolidating the bytes until a particular server child gets a chance to run. httpdito does a super stupid O(N²) thing in these cases where it looks for the CRLFCRLF at every position in the buffer after every received chunk (potentially a single frame), but this is ameliorated not only by Linux's TCP stack but also by the fact that the request buffer size is only 1024 bytes, so in the worst case we spend 4084 instructions on an incoming packet the last time we run this loop for a given client, and only half that (2042 instructions) on average. This is still fast enough to handle somewhere in excess of 4 million packets per core and probably faster than Linux's TCP stack.

The flip side of that is that by sending data slowly in this way, or by not sending any data at all, a client can monopolize all 2048 concurrent connections, preventing other clients from connecting. This is a problem that cannot be solved in TCP/IP, only ameliorated. httpdito ameliorates it with a 32-second timeout, counted from when it accepts, so in the steady state it always accepts an average of at least 64 new connections per second, regardless of how fast or slowly the requests come in.

I haven't tested darkhttpd under these conditions but it has a 30-second idle timeout and a 4000-byte max request length. It kind of looks like it does the same O(N²) thing, but I've only glanced at the code. I don't know how long it allows for the client to slowloris the initial requests in one byte at a time.

4. How the server behaves if the client receives the response very slowly: I think the above covers this. However, extremely large files or extremely slow connections will whack into the 32-second timeout. At 9600 baud, for example, responses of more than about 30 kilobytes will get truncated. There's an unavoidable tradeoff between handling slow connections successfully (which requires many memory buffers), handling fast connections efficiently (which requires large memory buffers), and withstanding DoS attacks (which requires, among other things, limiting memory use).

5. Whether the process will run out of memory if a number of events happen suddenly: httpdito does all of its within-process memory allocation at compile time, so this isn't a thing that can happen within a process. Its limit of 2048 children works out to about 16 mebibytes of RAM typically, so it's not a problem systemwide either, unless you're running it on a Rio Receiver or something. darkhttpd does allocate memory, but at first glance it seems to be limited to a couple of allocations of less than 4000 bytes per concurrent connection, so I don't see a problem here either.

It's common for event-loop servers to handle overload events like these much more gracefully than multitasking servers; httpdito is kind of an outlier here because it uses about a thousandth the RAM of a normal multitasking server, and running on an OS whose task scheduling is less shitty than is typical, which allows it to get away with a lot. (The original slowloris README describes it as a DoS tool for threaded web servers.) By contrast, the usual overload problem event-loop systems have trouble with is where some event handler that usually takes a millisecond or a microsecond suddenly starts taking a second or a kilosecond, locking out everything else until it's done. Maybe you have an O(N³) algorithm in your HTTP content negotiation, but you never noticed because normal browsers send an Accept: header with five content types and so N³ means 125 iterations, and then some guy in Turkey with a screwed up browser configuration sends you an Accept: header with 1296 content-types and your whole server freezes for several seconds. Every three minutes.

You could hypothetically make an event-loop system immune to this kind of thing by doing a rigorous WCET analysis on every single event handler, as if it were jet engine control firmware. But that's a huge pain in the ass for any program of more than about 1000 machine instructions, so I've never heard of anybody doing this with an event-loop-driven network server. I've been toying with ideas for solving this problem over the years, including approaches like BPF and software transactional memory. Some of my notes on this are at https://dercuano.github.io/topics/transactions.html, while others are in Derctuo and Dernocua.

That said, I haven't tested darkhttpd at all, and I'm not running any public services on httpdito. It wouldn't surprise me if either or both had some kind of stability bug under overload conditions. But it would surprise me very much if fixing those bugs required adding thousands of lines of code.

kragen16• 5 years ago

darkhttpd and things like `python -m SimpleHTTPServer` only support static content, so you can't run a chat server on them.

A lot depends on your context. I haven't benchmarked darkhttpd, but it's probably significantly better than my httpdito (linked above), which can spew out 1.8 gigabits per second and at least 20000 requests per second on my 8-year-old 4-core 2.3-GHz amd64 laptop. An event-driven server like darkhttpd would be a much better basis for adding Comet functionality like chat—that's why, at KnowNow in 02000, we contracted Robert Thau to move our Comet functionality from Apache with Perl CGI (IIRC ≈64 concurrent connections and ≈64 chat messages per second on a 1GHz server with 1GiB of RAM) to his select()-driven thttpd (≈8192). This work, now mostly of archaeological interest, has been open-sourced as mod_pubsub, which also includes a compatible select()-driven Python server I wrote the next year. It was also able to handle thousands of messages per second and thousands of concurrent clients.

There are at least four axes to your problem:

- How many concurrent connections do you mean when you say "a small chat server"? This could be anywhere from 2 to 2048.

- How many messages per second is it processing? This could be anywhere from 128 per connection (for something like Mumble) to 1/2048 per connection (if almost all clients are idle almost all the time).

- How big are these messages on average? This could be anywhere from 64 bytes to 64 mebibytes.

- What kind of hardware are you running it on? This could be anything from a 1MHz Commodore PET with an 8-bit 6502 and 16KiB of RAM to a 3.7GHz 12-core Ryzen 9 5900X with 256GiB of RAM. (I don't think anyone's written a chat server on Contiki, but it would be easy to do. It just wouldn't scale to very high loads.)

So, the answer to your question may vary by a factor of about 2⁷³, 22 decimal orders of magnitude. Can you give more detail on what you're thinking about?

nwsm• 5 years ago

Hug of death. A bit ironic!

commandlinefan• 5 years ago

Was it self-hosted?

jart3• 5 years ago

DarkHTTPD appears to be self-hosted on Apache. It's also configured to force HTTPS too, even if the Upgrade-Insecure-Requests header isn't present. That's one of my pet peeves.

the_arun• 5 years ago

This is very smart & creative.

Without stealing any bit of thunder from OP, there are Free/Open CDNs to host entire Blog package. All you need is a device/machine to generate static content & push them to these free CDNs (eg GitHub pages or Hostry).

kragen16• 5 years ago

If you want to clone a git repo from your laptop onto your cellphone (or vice versa), or test your CSS for iPhone 6 compatibility while you're actively editing it on your laptop, it's probably a lot less clunky to run a web server locally.

rkeene2• 5 years ago

I wrote filed [0], another single file HTTP server. It's very fast !

I wrote it because I was hosting containers (using LXC) on a laptop which only had mass storage available via a USB 1.1 (12mbps) connected drive. I was serving video streams out to the various Roku devices in my house from this container, but other webservers would do things very slowly (such as opening the file to serve out, which would require doing a lot of slow I/O) causing periodic interruptions. filed doesn't do those things.

It also supports Range requests (required to meaningfully serve media), and a few other things. If you want a static HTTP server, filed can work out quite well.

[0] https://filed.rkeene.org/fossil/artifact/d39c0feefb3f9113?ln

Ryan_Goosling• 5 years ago

doesn't load

WalterSobchak• 5 years ago

https://webcache.googleusercontent.com/search?q=cache:LfJkT-...

ActorNightly• 5 years ago

There is something even cooler that was posted last month.

https://justine.lol/redbean/index.html

jart3• 5 years ago

Author of redbean here. Thanks for the mention!

Thorrez• 5 years ago

Yep. darkhttpd is "Written in C - efficient and portable."

Portable, psh. How about a single that binary runs on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD and also contains all the files you want it to serve, and you can add files without recompiling.

IncRnd• 5 years ago

The site was down for me, but the archive of the site can be accessed this way.

https://archive.is/mXgB1

bullen2• 5 years ago

In 7000 lines I add multi-threading, non-blocking IO, dynamic responses, chunking and hot-deployment:

https://github.com/tinspin/rupy

Used in a product by 300.000 end-customers at 90% approval rating without rebooting for 4 years.

jiofih• 5 years ago

You need the Java runtime which is what, 70MB minimum and a few millions lines of code?

bullen2• 5 years ago

Yes, but you also need linux/windows and a c compiler...

The point is; the single file .c server is a toy, with my server you can make something real.

samtc• 5 years ago

thttpd (http://acme.com/software/thttpd/), mini_httpd (http://acme.com/software/mini_httpd/) and micro_httpd (http://acme.com/software/micro_httpd/) from acme software worth taking a look at.

secondcoming• 5 years ago

We use microhttpd in a few places. It's certainly lean but its API is odd and how to handle POST bodies is just weird.

stephc_int132• 5 years ago

Very small HTTP server is a common trick.

What I'd like to see is a very small HTTPS server ^^

rualca3• 5 years ago

There's another comment showing how to use OpenSSL to setup a https web server by providing a magic cli command.

stephc_int132• 5 years ago

Yeah, but using a lib for SSL is cheating, in this context, obviously.

zokier• 5 years ago

I wonder how small you could make TLS1.3 (or 1.2) implementation if you only supported bare minimum like single ciphersuite, no negotiation, no fancy features, no weird cert formats, but without skimping on the crypto parts?

userbinator• 5 years ago

As an order-of-magnitude estimate, probably a few KB of binary.

Galanwe• 5 years ago

Every one liner HTTP server is barely one `stunnel` away from becoming an HTTPS server ;}

AshamedCaptain• 5 years ago

Surprise, simple protocol with UNIXy roots is simple to implement on UNIX.

Now try HTTP3/QUIC or any of the other "let's just break all layering and abstraction for performance sake" stuff.

Matthias247• 5 years ago

The IETF version of QUIC isn't really that bad on layering. HTTP/3 is fully decoupled from the QUIC transport layer, and thereby e.g. stream multiplexing/flow-control is also fully separated from HTTP semantics (unlike in HTTP/2).

Handshake/TLS is also mostly decoupled from QUIC, as are flow controllers (recovery).

Compared to TCP is certainly has multiplexing as part of the main layer, and uses mandatory crypto. But that's more or less the point of QUIC.

deathanatos2• 5 years ago

HTTP/1.1 is anything but simple. E.g., https://news.ycombinator.com/item?id=26343577 .

This also doesn't correctly implement HTTP/1.1 (or /1.0). (It doesn't really claim to, either: the README really seems to hint that it is implementing a subset of HTTP that might work in a pinch. I don't think I'd put a production load on that, though.)

abrkn• 5 years ago

Beautiful!

textprotocol• 5 years ago

~113 sloc. lua. ucspi-tcp text://protocol server.

https://github.com/textprotocol/publictext/blob/main/publict...

pikseladam• 5 years ago

I'm not familiar with this concept. What you will do with a simple HTTP server? IOT applications?

ben509• 5 years ago

It's often handy for browsing documentation you compiled locally.

moiz_ahmed• 5 years ago

makes you appreciate things like flask

spaetzleesser• 5 years ago

When I look at this code it becomes clear that after using design patterns, dependency injection and other "modern" stuff for too long I have totally lost the ability to write short, concise code :-(

amelius• 5 years ago

That's possible because most of the server was already implemented in the OS kernel. The .c file only glues the components together.

1vuio0pswjnm72• 5 years ago

No one mentioned the httpd in busybox.

There are of course web servers everywhere now, sometimes in places that we really do not need/want them.

pmayrgundter• 5 years ago

Kudos! I've also found it nice to have a simple http server that I can build with simple tooling (just javac and run).

My single file HTTP/1.0-ish java http server, 300 LOC:

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
  100000 fetches, 10 max parallel, 1.024e+09 bytes, in 34.9176 
  seconds
  10240 mean bytes/connection
  2863.88 fetches/sec, 2.93262e+07 bytes/sec
  msecs/connect: 0.0995282 mean, 2.717 max, 0.037 min
  msecs/first-response: 3.18724 mean, 202.23 max, 0.315 min
  HTTP response codes:
    code 200 -- 100000

known• 5 years ago

You can check https://rosettacode.org/wiki/Hello_world/Web_server

johnisgood• 5 years ago

I love rwasa: https://2ton.com.au/rwasa/ (flat assember (fasm))

rwasa is our full-featured, high performance, scalable web server designed to compete with the likes of nginx. It has been built from the ground-up with no externel library dependencies entirely in x86_64 assembly language, and is the result of many years' experience with high volume web environments. In addition to all of the common things you'd expect a modern web server to do, we also include assembly language function hooks ready-made to facilitate Rapid Web Application Server (in Assembler) development.

I love the fact that it uses flat assembler! It is worth checking out their other stuff: https://2ton.com.au/Products/

For example https://2ton.com.au/HeavyThing/ supports Curve25519/Ed25519, SHA3/Keccak, SHA512, SHA384, SHA256, SHA160, MD5 HMAC, PBKDF2, scrypt, HMAC_DRBG, and Poly1305. It is quite impressive.

An HTTP server in a single .c file

Related Stories