Question: I thought any given C code could go in either headers or c files (or rather, split between headers and c files), and that the difference was only a build concern. So why wouldn't a given library be available in both forms, unless one of them just makes no sense at all? Put differently: why isn't this just "Minimal library for writing non-blocking HTTP servers in C" which people understand to mean "this might make sense to put in a header"?

h2o [1] is a web server and C library that not only supports http 1 & 2, but also usually tops the TechEmpower benchmarks [2].

[1] https://github.com/h2o/h2o

[2] https://www.techempower.com/benchmarks/

1100+ lines and barely a comment after the initial block.

It also defines some buffer size names that are likely also declared in other libraries, like `BUF_SIZE`, and will need to be `#undef`ed.

^Fchunked

No chunked support. Well, if ever I use this (and... I do have a pressing use for something like this), that will be a PR I'll send in, probably using async.h[0] to allow handlers to be asynchronous.

Also, it's no fair to compare this server's performance to nginx if this server has no TLS support: you'll have to setup a reverse proxy, and then what will that be?

The lack of URI parsing is not a big deal for me, but it'd be nice.

[0] https://github.com/naasking/async.h

I like this. I've become a huge fan of using Go for web stuff since it's baked in to the language and I can get solutions really quickly. I'm more likely to go through this code though because it looks interesting.

I had good luck with microhttpd. I wrote a little json web service as part of an existing C application for an embedded platform. Was very DIY but this is C after all.

It's non-blocking for its own http request/response handling but will it allow you integrate with its event loop and register your own events to react to? Can your request handler make its own network connections as a client to other servers in a non-blocking way?

Any sort of static analysis to argue this doesn't have undefined behaviour bugs? It's cool, I just don't know a lot of cases where I would want/need an HTTP server and wouldn't want something more weathered

Neat, but why? Is it just the novelty that it can be done?

I thought it was poor form to have a lot of code in headers. This seems like it'd be better served as a small C http library.

At first glance this doesn't seem to handle large amounts of body data?

Also I find no handling of slow connections.

This is definitely a toy.

Might go well with embeded hardware

You forgot to add "for Linux/BSD".

Great job. For me, checks all the boxes:

. C (could have been C++... embedded MCU platform)

. compiles cleanly out of the box

. demo is simple, works out of the box, simple to verify

I contrast this with my experience a few days ago with the "Space Invaders in C" post (too lazy to reference it or find the exact title). I do development on my Mac all the time (command-line, C++, clang/gcc). Tried building Space Invaders. One problem after the next. Gave up after about 20-25 minutes.

Cliché as it is, the importance of the "out of box" experience is so important. Especially for a commercial product, which I realize this isn't.

I now use mostly Lisp languages (or Haskell), but back in the day I wrote C++ books, acted as a C++ trainer and tech lead. My last professional use of C++ was in the 1990s doing entertainment game, VR, and game AI for SAIC, Nintendo, and Disney.

I then went back to using plain C for awhile, and after the complexity of C++, C was so much fun to use.

Anyway, I enjoyed reading through this C header file, and it took me back. But, I am sticking with Lisp because for me it is such a higher productivity language.

I like that it looks like Node.js http module. But I'm too scared to use C with pointers and malloc, so I'll stick to Node.js. I'm however jealous of people that are competent in C, assembly or any other low level systems language.

What about Windows?

You can get a 3-for-1 with this kind of library by having a libuv implementation.

brundolf is asking a similar yet different question, so I'll ask mine: I've heard about modules coming to C++. What are the concerns with headers exactly? I'm aware of the issues with duplication in object files and ballooning build times, but are there other issues? Is it then something that primarily affect very large code bases?

Securely?

Surprised to see no CI.

This kind of thing is the reason that header files should die and a new module system should emerge in the world of C/C++. "Header-only" should stop being a novelty. Distributing or consuming libraries should be much more straightforward and easy as with modern languages. I'm not sure C++20 modules are the solution, but this certainly isn't.