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

31–40 of 70 posts

Re: Raphters, a web framework for C

#31

Post by nkurz »

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'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 a problem if you are doing it by hand on a per field basis. Which leads to your next point:

  >  Maybe you can do an arena for each connection, so it's:
  >  char *hsafe(request_t *r, char *str)
  >  But that's still sort of painful.
This is only painful if you are doing it by hand every time you use the parameter. If the framework handles it for you, so that you always get the sanitized result, it strikes me as no different than any other language.

r->param("input"); // presanitized, lazily created, pooled in r

r->param_raw("input"); // if you want to live dangerously

Why is this worse in straight C than in something like Python that is doing the same thing but with an interpreted layer between you and the C?

Re: Raphters, a web framework for C

#32

Post by jedsmith »

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.

Re: Raphters, a web framework for C

#33

Post by jrockway »

dasil003 wrote: post #21
ognyankulev wrote: post #12

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

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

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

Re: Raphters, a web framework for C

#34

Post by JoachimSchipper »

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…

If you're going for clean syntax, you could store an arena pointer in a global variable/thread local storage (depending on the programming model). Just make sure the scaffolding switches/creates/destroys the arenas. I think you'd still want a hierarchical allocator, though.

Re: Raphters, a web framework for C

#35

Post by rch »

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…

You might look here before starting from scratch in C: http://okws.org (C++)

Re: Raphters, a web framework for C

#36

Post by tptacek »

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

Re: Raphters, a web framework for C

#37

Post by DTrejo »

compay wrote: post #11

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.

Came across this the other day:

Embed the Power of Lua into NginX https://github.com/chaoslawful/lua-nginx-module

Re: Raphters, a web framework for C

#38

Post by tptacek »

JoachimSchipper wrote: post #30
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…

Something like evhttp also has the benefit that you can have more than one request "in flight". FastCGI can theoretically do this, but almost no implementation supports it - and it makes e.g. writing a simple chat server much easier (one process, one thread, tons of connections, data in memory.)

The downside to doing evhttp is that he'll have to write his own request parsing (I think he's relying on Apache/CGI to do that for him now).

But if you're going to do a C web framework (and... really? you sure about that?), that's probably how you should do it.

Re: Raphters, a web framework for C

#39

Post by tptacek »

nkurz wrote: post #31
tptacek wrote: post #20

Earlier quoted context omitted.

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

Re: Raphters, a web framework for C

#40

Post by VladRussian »

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.

in correct functional style shouldn't it rather be :

response_set_status(response, 200);

no issues with global state, threading (if correctly mutexed), etc...

Post reply on HN