Nope.c – A web framework with a tiny footprint

http://nopedotc.com/

by amandle • 12 years ago

108 52 12 years ago

nopedotc.com

bebna2• 12 years ago

Better use nxweb, this one isn't that secure: http://www.reddit.com/r/programming/comments/2bo44u/i_am_the...

idlewan3• 12 years ago

Clickable: https://bitbucket.org/yarosla/nxweb/wiki/Home

cremno• 12 years ago

There is also https://kore.io/.

bebna2• 12 years ago

I wanted to include that one too, but I always forget the name of it when I need it.

acidx• 12 years ago

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)

idlewan3• 12 years ago

Duda is also a good alternative: http://duda.io/

captainmuon• 12 years ago

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.

nyir• 12 years ago

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).

616c2• 12 years ago

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.

icebraining• 12 years ago

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.

cordite• 12 years ago

9.7k with everything inline can do that.

JimmyM• 12 years ago

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.

FraaJad• 12 years ago

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.

pavlov• 12 years ago

Google Go is a popular way to do it.

616c2• 12 years ago

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.

pjmlp4• 12 years ago

It is the speed of using a language with a compiler.

Artemis2• 12 years ago

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.

paraboul• 12 years ago

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.

idlewan3• 12 years ago

Yes, it uses lots of strcpy and sprintf instead of strncpy, snprintf or strlcpy. It's bound to be exploited.

meowface• 12 years ago

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.

eq-2• 12 years ago

It depends. It's not like there's no safe way of using strcpy and sprintf.

joliv• 12 years ago

Why do you think it's called "nope.c?" ;)

yaph• 12 years ago

Apparently people are taking advantage of that right now...

pjmlp4• 12 years ago

That is what happens when language designers decide to throw away design decisions from Algol.

asveikau2• 12 years ago

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.

jackweirdy• 12 years ago

"This webpage is not available"

Yuioup• 12 years ago

It's probably already been compromised since C has no bounds check whatsoever.

filmgirlcw• 12 years ago

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.

vesinisa• 12 years ago

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.

jahaja• 12 years ago

Feels like an educational project. So I wouldn't be too harsh on the author. Should've probably made it more clear though.

craigching• 12 years ago

Seems more like a play on node.js to me.

eq-2• 12 years ago

So would a ridiculously slow PHP framework be an example of why we don't code serious web apps with PHP?

general_failure• 12 years ago

The code is filled with bloopers.

callesgg• 12 years ago

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.

nly• 12 years ago

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)

zxcdw• 12 years ago

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.

jvandonsel• 12 years ago

Minor comment in your sample code: When searching for factors of N you only need to search up to sqrt(N).

regi• 12 years ago

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

datenwolf• 12 years ago

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).

synack• 12 years ago

Calling recv one byte at a time is high performance? Nope.

natch• 12 years ago

First link on the documentation page is:

Build a simple app using node.c

node? Typo?

zidar• 12 years ago

Could be a typo, or a freudian slip.

anon4• 12 years ago

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.

abimaelmartell• 12 years ago

Poorly coded, no standards, also is vulnerable to DOS and memory leaks...

peterwwillis• 12 years ago

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.

forgottenpass• 12 years ago

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.

Nope.c – A web framework with a tiny footprint

Related Stories