

Raphters, a web framework for C - DanWaterworth
https://github.com/DanielWaterworth/raphters

======
tptacek
Interesting, but very minimal. It's basically a wrapper around FCGI (meaning
it's doing the old-school "pull request data out of environment variables"
thing) with a linked list of regexes matching handlers. That's not nothing;
"registered list of regexes matching handlers" is a proven good model for web
frameworks and it's handy to have.

On the other hand, if I was going to release a web framework, I might do more
to abstract request variables (provide a params hash like Rails, or a Rack-
style request hash). Also: I'd probably build it on libevent's evhttp instead
of demanding that users plug my C code into FCGI.

~~~
jedsmith
A little off-topic, but you sound familiar with libevent.

I've never used either but I'm looking at gevent for a project, and I noticed
that they switched to libev: <http://software.schmorp.de/pkg/libev.html> ...
do you know what "limitations and bugs" in libevent they speak of? I poked
through the mailing list for libev and couldn't find anything specific.

~~~
tptacek
I've never paid much attention to libev. I've been using libevent since 2002
(it was the standard event loop at Arbor Networks, which was in Ann Arbor,
where Niels Provos lived at the time). Before libevent, I used ACE_reactor to
accomplish the same tasks. I prefer libevent (strongly) to ACE. I might prefer
libev to libevent, but... why bother? Libevent works fine.

My guess about "limitations" of libevent is that it's primarily that libevent
is anchored to global state and needs to own the event loop for the program.
So, for instance, to get it working in Cocoa apps, I have to spawn off a
libevent thread. And I can only have one of them.

But this isn't really a big deal for me; once I got the libevent thread
working, everything was peachy for me.

In no other context do I ever, ever have any need to do anything funky with
how I include libevent; 90% of programs that use libevent are designed from
the outset to use libevent and don't benefit from flexibility about the event
library.

------
rbranson
This is neat.

Honestly, in addition, I'd like to see something like Rack for C. The "gateway
interfaces" for C are too implementation-specific (CGI, FastCGI, SCGI, web
server extensions/modules, etc). It would be something more abstract that
would run on-top of a web server interface.

    
    
         void application_main(web_request *request, web_response *response)
         {
              char body[1024];
    
              snprintf(body, sizeof(body), "Hello, %s", request->param("username"));
    
              response->status(200);
              response->header("Content-Type", "text/html");
              response->write(body);
              response->end();
         }

~~~
roel_v
Rather:

    
    
        response_set_status(200);
        response_set_header("Content-Type", "text/html");
        response_write(body);
        response_end();
    

The awkwardness of which, to me, demonstrates the superiority of C++ in this
regard.

~~~
jerf
That implies some global state somewhere being updated, and now you've given
up on threading. This may be OK, but it's still dangerous and leaky even if
you give up on threading.

There are various solutions that still allow you to pass a set of closures
without being particularly more ugly than anything else is in C, for instance,
see [http://library.gnome.org/devel/gobject/stable/chapter-
signal...](http://library.gnome.org/devel/gobject/stable/chapter-
signal.html#closure) . C++ still ends up nicer, my point is just that you can
do good things in C and there are libraries that implement the stuff for you.

That said, if I were really going this route I probably would try to go with
some sort of minimal C++. Then again, my opinion is suspect, as I would never
go this route anyhow. Web developers writing in languages that don't permit
buffer overflows write software that has all the security of a colander;
adding the ability to write good, solid buffer overflows as well hardly seems
like a step up. You _can_ write secure C code, but you _can_ write secure PHP
code, too. Existence proofs of secure code aren't very interesting.

~~~
DanWaterworth
You're right, web developers already write software with all the security of a
colander. You can go one of two ways, 1.) you can devise a language that can't
express an insecure application or 2.) you can teach people about security. I
know which option I prefer.

~~~
tptacek
Overly reductive. There is an actual security benefit to using environments
that minimize memory corruption. Educating devs helps, but educated devs _do
not_ reliably avoid memory corruption.

------
compay
It would be neat to see how you could possibly hook Lua into this to give you
some of the flexibility of a dynamic language with the speed and small
footprint of a (mostly) C app. I've been thinking of working on something like
that for a while but unfortunately my C skills need a lot more work before I'd
be comfortable tackling it.

~~~
DTrejo
Came across this the other day:

 _Embed the Power of Lua into NginX_ <https://github.com/chaoslawful/lua-
nginx-module>

~~~
1337p337
There's also AbsoLUAtion for Lighttpd. Lua's a very nice, convenient language
for embedding dynamic/user-configurable bits in otherwise static applications.
PowerDNS and nmap use it, too. It seems to have displaced Tcl as the de facto
language for embedding.

------
sunkencity
Pretty cool, but if I really had to write some kind of C stuff to output web
pages I suppose I'd just build it as an apache module rather than go the CGI
route, there's lots of useful functions and nifty stuff within apache making
it a pretty nice environment for serving stuff.

(Or more probably since it's 2011, I'd try an nginx module (or lightty),
although I have never looked at any of those projects code yet).

Building response stuff in C is pretty high maintenance stuff though.

~~~
chuhnk
Funnily enough this was going to be my starting point into writing a C webapp.
I felt that by writing a C module directly embedded in an existing web server
it would allow me to leverage the request handling. Having already done
bugfixes for apache C modules are work it felt the most relevant path to take.
The problem I see with it though is you are bound to the webserver you write
the module for. Portability would be nice.

------
burrows
There was some issues with the code. Mostly memleaks. I think I've fixed most
of them, although it was tough to do so elegantly. You may want to rethink
using the START_HANDLER macro (or at least restructure it) as it makes it
difficult to correctly handle errors with writing a response. I've addressed
this issue in RAPHT and offered a fix. However I think I complete rework is of
that subsystem is probably better.

I'm at work so I can't setup a server to test, however after summoning my
inner compiler my changes seem sane. But you should look them over (check the
pull on github <https://github.com/DanielWaterworth/Raphters/pull/2>).

I'll be around if you want to discuss a proper fix for some of the issues.
Albeit it will take a pretty major rewrite.

------
swah
Can't we just have a minimal webserver for ZeroMQ, and from there all the
languages with ZeroMQ bindings?

~~~
sophacles
You mean mongrel2?

~~~
swah
Yeah, that could work too.

------
wingo
I thought at first that this was named for Raph Levien
(<http://en.wikipedia.org/wiki/Raph_Levien>) who wrote Advogato in C, some 10+
years ago. But no mention of that in the README or RAPHT. Too bad :)

~~~
DanWaterworth
Until you mentioned him I never even knew he existed.

------
joelmichael
A couple of years ago, I also embarked on a mad project to create a web
framework in C. I wrote a scandalous and regrettable blog post about it which
got on Hacker News and I have since taken down. You can find what remains of
the unfinished project here: <https://github.com/joelmichael/memereap>

------
antihero
And still, be blocked by IO.

------
supervillain
This is awesome, reminds me of the days of writing CGI apps in bash.

------
ignifero
Very refreshing, a time tunnel straight to 1994.

------
ognyankulev
This framework does almost nothing. I don't see the point of it.

~~~
dasil003
The point is that with sufficient pathology you can do high-level things in a
low-level language, but not the inverse.

~~~
jrockway
Too bad the point isn't true?

I've write code that looks nearly identical to C in Haskell all the time.
(Except, of course, that `alloca` is faster than malloc and is garbage-
collected.)

------
jamesshamenski
The title is like saying, 'running shoes for grandma'.

