Nope.c – A web framework with a tiny footprint (opens in new tab)

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.

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.

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)

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.

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.

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

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

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

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.

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

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.

The code is filled with bloopers.

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.

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.

"This webpage is not available"

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

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

First link on the documentation page is:

Build a simple app using node.c

node? Typo?