Nope.c – A web framework with a tiny footprint(nopedotc.com) |
Nope.c – A web framework with a tiny footprint(nopedotc.com) |
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.
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 wonder if it is just the lightweight HTML the websites use, or if there is really so much speed to gain from using a compiled language.
http://forum.dlang.org/ Code: https://github.com/CyberShadow/DFeed
If one insists on writing a webapp in a C/C++ like language, D might be the sane way to do it.
http://nopedotc.com/gallery/facedetector
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.
Isn't it odd that this kind of minimalism is now considered novel?
(Not that I'm bashing the author. Doing this stuff was fun in the 90s and it's still fun now)
Compare to someone writing a 3d software renderer, not so many people can relate to it, as they can to things related to web.
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.
https://github.com/datenwolf/litheweb
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).
Here's something that is probably safer and that actually scales: https://github.com/reginaldl/librinoo
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.
(In time, my project's web page is at http://lwan.ws)
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.
Even tho people here on HN seams a but harsh there is some good lessons to be learned from them.
Sockets are library/OS responsibility.
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.