Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raphters, a web framework for C

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Raphters, a web framework for C

#51

Post by FooBarWidget »

jedsmith wrote: post #32
tptacek wrote: post #19

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 t…

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.

I have minimal experience with libevent and much more with libev, but I do think that libev is very, very well-engineered. The author is on steroids, you can really notice it just by reading the documentation. The documentation and the code indicate that he knows what he's doing and is very serious about performance. There are also no obvious design flaws in libev that would result in limitations. Want fork? No problem, but be aware of clearly documented issues A B and C. Want threads? No problems, it even documents how, as well as potential issues. Want signals? No problem, and again potential issues are clearly documented.

Re: Raphters, a web framework for C

#52

Post by rubashov »

roel_v wrote: post #5
rbranson wrote: post #4

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", reque…

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.

All the pieces to do the whole framework are already in POCO and other libraries, with ssl and cookies etc.

http://pocoproject.org/docs/Poco.Net.HTTPResponse.html

http://pocoproject.org/docs/Poco.Net.html

Doing this in C seems silly to me.

Re: Raphters, a web framework for C

#53

Post by tptacek »

FooBarWidget wrote: post #51
jedsmith wrote: post #32

Earlier quoted context omitted.

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.

I have minimal experience with libevent and much more with libev, but I do think that libev is very, very well-engineered. The author is on steroids, you can really notice it just by reading the documentation. The documentation and the code indicate that he knows what he's doing and is very serious about performance. There are also no obvious design flaws in libev that would result in limitations. Want fork? No probl…

Niels (of libevent) is also pretty ridiculously talented; it's also hard to dispute that libevent has had more testing.

Libevent vs. libev really seems like a Linux vs. BSD kind of debate. I'd always choose libevent over libev, but you can apparently get a performance improvement (which is probably going to be marginal compared to other simple things you can do to speed up an evented program) by going with libev. And it looks like if you're doing clientside dev, like building a new browser or file transfer client, that libev is easier to embed.

Re: Raphters, a web framework for C

#54

Post by crux_ »

tptacek wrote: post #20
rbranson wrote: post #4

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", reque…

As an illustration of why C kind of sucks for web apps, that code is obviously insecure† (it's reflected XSS). To get around that while preserving natural syntax, you want: char *hsafe(const char *input); But where does hsafe get the memory for the string from? It can't use input (the filtered result is larger than the input). Does it malloc? Now you have to free the result. Does it do the inet_ntoa() thing with the…

I think part (far from all!) of the issue is that you (and parent) are not using the right abstraction: The response body shouldn't be a string; it should be a stream:

   write_quot(response,"this ");
Not perfect (you still need to deal with allocating temporaries if you want to inspect the contents before sending to the client), but: it (a) matches what's actually going on under the hood, (b) makes the simple cases safe, (c) provides a decent interface for safely extending the available formatters. (They would write their output to the stream, then free all temporary resources themselves before returning.)

(Further, I've had enough influence from statically-typed-land that I'd personally want to create tainted wrapper structs so that the compiler helps prevent user data from being passed to an unquoted write... but that's just me.)

Re: Raphters, a web framework for C

#55

Post by 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

Re: Raphters, a web framework for C

#57

Post by antihero »

jedsmith wrote: post #32
tptacek wrote: post #19

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 t…

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.

There's also picoev to look into if you're interested in seeking alternatives to libevent. I don't know a huge amount about libevent and it's a bit niche, though. The meinheld WSGI server uses it, and I got nearly double requests/second compared to gevent (libevent). Not that that means much, but it's interesting.

Re: Raphters, a web framework for C

#59

Post by nkurz »

tptacek wrote: post #39
nkurz wrote: post #31

Earlier quoted context omitted.

I'm not seeing this a problem with C, but perhaps I misunderstand. Your goal is avoid including anything executable in the page. The filtered result is only larger than the input if you need the ability to faithfully quote the potentially malicious code. In this particular contrived example, you could "just" strip it out and make it shorter, or even error out if you see anything suspicious. Which is to say it's only…

You need to convert < into &lt;. That's the price of entry. You can't redefine the problem to "web framework that simply strips < out of inputs". Your framework would then be immediately inferior to every other framework which does output quoting.

Yes, if it was done in the framework, you'd want to have the sanitizing and allocation happen seamlessly, and you'd want the memory management to be simple as well. My confusion was why this strikes you as a significant difficulty for a framework author to set up.

Certainly it's harder if you decide that you are going to work from the ground up in straight ANSI C, but there's lots of good pool memory allocators out there. I'd either use one I had laying around, or just link in the one from the Apache Portable Runtime: http://apr.apache.org/docs/apr/1.4/group__apr__pools.html

The framework author could easily hide this behind the scenes, so that the user would find the string creation and destruction just as seamless as in Perl or Python. Use it and forget it, and the pool would be freed along with the Request. Thus my question, and my confusion, was why you finished with "But that's still sort of painful."

Re: Raphters, a web framework for C

#60

Post by DanWaterworth »

wingo wrote: post #48

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

Until you mentioned him I never even knew he existed.
Post reply on HN