Nope.c – A web framework with a tiny footprint(nopedotc.com)
nopedotc.com
Nope.c – A web framework with a tiny footprint
http://nopedotc.com/
18 comments
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.
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.
Poorly coded, no standards, also is vulnerable to DOS and memory leaks...
Better use nxweb, this one isn't that secure: http://www.reddit.com/r/programming/comments/2bo44u/i_am_the...
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.
(In time, my project's web page is at http://lwan.ws)
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)
Duda is also a good alternative: http://duda.io/
There is also https://kore.io/.
I wanted to include that one too, but I always forget the name of it when I need it.
This site feels ridiculously fast. I've noticed that with other compiled frameworks too, e.g. CppCMS: http://cppcms.com/wikipp/en/page/main
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.
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.
Commenters on this site had similar observations about D language's forum, which is written in D.
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://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.
They're completely static pages with no images; it's not hard to get that kind of speed. For example, sqlite.com seems just as fast to me.
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.
I tested this page because most of the site is too small to get meaningful comparisons:
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.
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.
9.7k with everything inline can do that.
It is the speed of using a language with a compiler.
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.
Looking at the source code : https://github.com/riolet/nope.c/blob/c883b11df78bb8115d5e51...
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.
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.
Why do you think it's called "nope.c?" ;)
Yes, it uses lots of strcpy and sprintf instead of strncpy, snprintf or strlcpy. It's bound to be exploited.
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.
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.
It depends. It's not like there's no safe way of using strcpy and sprintf.
The safe way to use strcpy is to use strncpy
no，strncpy is worse than strcpy，the right way is strlcpy.
That is what happens when language designers decide to throw away design decisions from Algol.
Right, because Algol had non-blocking sockets.
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.
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 was speaking about unsafe by design.
Sockets are library/OS responsibility.
Sockets are library/OS responsibility.
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.
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.
Apparently people are taking advantage of that right now...
"This webpage is not available"
It's probably already been compromised since C has no bounds check whatsoever.
I think HN just broke your server.
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.
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.
Feels like an educational project. So I wouldn't be too harsh on the author. Should've probably made it more clear though.
So would a ridiculously slow PHP framework be an example of why we don't code serious web apps with PHP?
Seems more like a play on node.js to me.
The code is filled with bloopers.
Nice try, a bit buggy but nothing that can't be solved.
Even tho people here on HN seams a but harsh there is some good lessons to be learned from them.
Even tho people here on HN seams a but harsh there is some good lessons to be learned from them.
It's strange how a piece of code any dev could, and likely would, have written in 1992 can now reach the HN front page.
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)
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)
Remember that most of us are web devs. It's web stuff, it's very simple and minimalist, it's easy to look at it and go "yeah, cool".
Compare to someone writing a 3d software renderer, not so many people can relate to it, as they can to things related to web.
Compare to someone writing a 3d software renderer, not so many people can relate to it, as they can to things related to web.
Minor comment in your sample code: When searching for factors of N you only need to search up to sqrt(N).
How come this code has 117 stars on github?!
Here's something that is probably safer and that actually scales: https://github.com/reginaldl/librinoo
Here's something that is probably safer and that actually scales: https://github.com/reginaldl/librinoo
I responded on Reddit with a link to my litheweb (the sources still say picoweb throughout it. I yet have to rename-refactor it).
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).
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).
Calling recv one byte at a time is high performance? Nope.
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.
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.