You're right. "Header only" libraries are an anti-pattern in C and the fastest way for me to close the tab when considering a new library. Just put it in two files and it's still dead easy to incorporate into a project.
I don't really understand what your criticisms are. There is literally no functional code difference between a single header library and a two file library. Your aversion is as arbitrary as saying you don't consider libraries if the API uses camel case.
I can sort-of understand (and still disagree) for header-only template libraries. But in general yes I agree, "header-only" is an anti-pattern for high quality C and C++ projects.
Separating the interface from the implementation details? Isolating the server code from the module that uses it? Because the implementation is in the header, including it defines a bunch of macros that could easily collide with macros in the larger project.
Not knocking the overall effort here, but yes, "header only" libs are definitely an anti-pattern in real world C. I assume the author considers it a curiosity, a novelty, or something that would only be used in very limited circumstances that make such a design an advantage.
Still suffers from the isolation problem. For example, if you happen to define HTTP_BODY in your own code, it segfaults.
This can be avoided by being careful to only define HTTP_BODY after including httpserver.h, but avoiding this type of thing to worry about is the entire point of interface/implementation separation.
Well yes, it's a small isolation failure, but a failure nonetheless. It may seem like a contrived example, but "HTTP_BODY" would be a perfectly reasonable choice of variable or macro name for someone building a tiny embedded web server, and then you have a user (the user in this case being a developer using your library) having to debug your code because its internal assumptions collide with the outside world in a way that's completely avoidable if you just put it in a separate compilation unit.
How is that different.from anything else in C or C++? What does that have to do with single header libraries? Preprocessor isolation is just now possible with C++ modules.
It's different because normally your header files don't contain internal implementation details like this that spill out all over everyone who #includes them.
100% agree with you. I really think adding a source file to your build tool of choice (Make, CMake, Visual Studio project) is a basic fundamental skill that a C or C++ developer should know.