Not only just that, but it seems in many cases there is absolutely no bounds checking whatsoever. There are legacy libraries out there that use the str* group of functions safely, because there is careful bounds checking before each call. That's still far less reassuring than just using safe functions, but it's better than absolutely nothing.
Based on the inconsistent use of tabs and spaces, lack of whitespace around any sort of operators or special syntax, and total disregard for security, this looks much more like a 1995 project than a 2014 one.
Some of these mistakes transcend the language. Unfamiliarity is one thing but I don't believe you can take someone who writes C code like this and they'll instantly do a stellar job in some other language.
I believe you missed my point, though. I will grant you that many libc functions do not follow what are currently considered best practices.
But you can't take the textbook example of what not to do and say that this is representative of everyone who works in the language. Just as I can't take an example of extremely bad code in some high-level language, which naively goes against what is considered sane practice, and say it's the language's fault.
Put alternatively, in many contexts an out of bounds exception is almost as bad as the trouble you can get into with pointers. [I say "almost", conceding the point that with the C you can do crap like clobber a return address on the stack.] Someone who simply doesn't give a shit about array bounds (like this author, it sounds like) is not likely to be totally saved (as if by magic) by a higher-level language.
It is, because crashing is a better alternative than wounding the process and keeping on running producing bad results, or corrupting memory state and crashing anyway on a total unrelated part of the application.
Nimrod is also becoming a real possibility, check out the Jester framework. I forget the other's name, but it did reasonably well on TehcEmPower benchmarks and runs behind the Mongrel2 web server via ZeroMQ sockets. Very cool stuff.
Yes, there are definitely huge speed gains possible and if you choose an implementation which is still interactive you get the benefits of both (I know one particular example in CL: teepeedee2, there are some blogs posts, e.g. http://john.freml.in/teepeedee2-c10k or so).
I have seen it come up many times, but is anyone still using it or tried it long term? I checked a year ago or so and it appears both Git commit-wise and blogwise Fremlin had moved on to better things, but when people dismiss Lisp, I don't say it out loud but I immediately think of this project.
It is faster to load than a highly optimised page which is half the size running on a more conventional stack.
The initial DNS request was the biggest saving on time, though, weirdly enough, followed by the time to connect. I have no idea why this is, or how to minimise DNS request time in general.
People... please. Don't implement protocols or network servers yourself. There's about a billion http servers out there, and some of them are even good. Most popular http servers let you compile custom modules that run in the same process, which would have the same effect as Nope.c but without all the flaws.
If you need a C http implementation with a tiny footprint, grab a tiny http server that has been around for a long time (there are many) and hack on it. Busybox httpd, thttpd, boa, etc all come to mind, and there's probably dozens more. But even those support CGI, and it'll be much more scalable to not have to re-compile and re-ship and re-start your entire http process every time you need to edit a page.
Write your CGI/FastCGI/whatever app in C, compile it, and let the http server run it. It's much better suited to deal with securing the connection and handling the fucked-up edge cases of different browsers, platforms, proxies, RFCs, tcp/ip stacks, etc etc etc. As a hack, if your environment has a shell, write your CGI web apps in shell script; it compresses great, can be edited on the fly, and uses existing system resources.
I have written http server implementations. I have written boatloads of server-side applications. I've even written an entire CGI web interface and framework in C. It's fucking abysmal. Unless you're writing a hello world app, trust me, you don't want to use C.
Edit: Just read the linked Reddit thread, looks like there were some security issues. But hey, that's the power of open source, right? People can tell you instantly when shit is broken or unsafe.
I think this post is a joke of some sort ("nope.c"), example of how not to do things and why we don't code web apps in C. The "web server" is just ridiculously badly designed.
Lithweb is developed network API agnostic and requires no dynamic memory allocation (malloc/free). Its main target are microcontrollers and it has a memory footprint of as little as 0.5kiB. To make it work you'll have to provide an implementation of the ioops functions.
GET variable support has the scaffolding up, but URL parameter parsing not yet implemented.
However POST request support it fully implemented, including MIME Multipart reconstuction.
See the test/bsdsocket.c for an example on how to implement ioops and for a file upload example.
So far the repositry does not contain the tag nesting functions, but I have those, too.
Security issues? Probably some but so far not identified yet. However when I tried fuzzing it, the fuzzer got crashed by litheweb %) (litheweb was not impressed).
As I'm writing a web server as well (just for hobby, won't be big and professional like nginx), I did glance at Nxweb's code a few months ago. It's pretty hard to grasp, and I consider myself to be a pretty experienced C programmer. Hard to grasp code usually raises some red flags, security wise. It does perform well, though, and has some pretty interesting ideas. It is well worth looking, even if for learning a thing or two.
The Reddit thread for Nope.c is generating a lot of constructive criticism. It ranges from stylistic issues to security issues to architectures issues. Nope's author might learn a lot of stuff and have a lot of fun -- I sure did when writing my own.
Why wouldn't one write something like that directly as an httpd or nginx module? You get fastest possible C http server, together with a very good utility library and just need to write your own routing and handling functions. I mean, why rewrite the server component when you can just use an existing one? I can see not wanting to use one of the CGI interfaces for maximum performance (and ultimate fun), but there's very little point in rewriting the http(s) handling yet again.
When you cross-posted this from reddit you forgot to retain the context:
I am the developer behind nope.c: an ultra-lightweight network application platform for C language. It's early days, so, could I have some feedback please? Thanks. And, yes, the website is hosted runs on nope.c.
Sure it's buggy as hell, but it doesn't actually matter yet because the author isn't presenting it as more developed than it is.
Looks great! You might want to fix the "node.c" that appears on a few pages (for instance the documentation), and limit the maximum value one can input into your factors calculator.
It tries to copy a buffer of 1024 byte (max) into a buffer of 512 bytes (by executing a request with an URL longer than 512 bytes).
It also runs 15 children process and use blocking socket, meaning that it's easily "DoS'able".
The overall code seems very "unsecure" and poorly designed.