Rise and fall of (Fast)CGI
Early days of services development for internet were pretty dark. At the very beginning there little to no reason to have any actual logic in the back of a web page because page of the nature of those pages. HTML back in 1999 was meant to be read and mostly by a very few people. And such as there was no need to pass anything back to server, there was no backend.
Then things developed and there were forms. And forms were nice and all and let you finally pass some data back to the server and process it. And there we have all of the early web-dot-com developments based on a simple idea of passing a form data back to server. But this is a moment when all of the modern vulnerabilities come from from XSRF to SQL injections - its all about user input at its core.
So handing this data from clients was given to a special programs adhering to Common Gateway Interface - CGI.
That software doesn’t need to be part of the webserver software itself. It can be a separate program, called by the webserver software when a request comes in, and responding by returning the constructed document to the webserver software, which in turn sends it back to the requesting client (usually, a web browser that displays it to the end user). In the early days, such programs were usually small and written in a scripting language; hence, they were known as scripts. (from Wikipedia)
But CGI wasn’t all that great really. Truth is it was pretty bad and was prone to some design problems. Main thing was the fact that web server spawned a new process on every request, not a very performance wise idea. And even as external script, CGI programs were subject to numerous security attack.
CGI scripts are potential security holes even though you run your server as “nobody”. A subverted CGI script running as “nobody” still has enough privileges to mail out the system password file, examine the network information maps, or launch a log-in session on a high numbered port (it just needs to execute a few commands in Perl to accomplish this). Even if your server runs in a chroot directory, a buggy CGI script can leak sufficient system information to compromise the host. (from w3.org)
Enter the Kore
The Kore Framework is a minimalistic and secure C framework to build backend of all kinds. And most obvious reason to use it is it’s TLS first by design, no plain data ever. You can check the list of features to be sure that Kore supports what you need.
But for me Kore is basically all there is a need for to just handle and serve requests fast and surprisingly easy (we’re talking C here, not ever C++). The framework is geared towards state-machine services where state itself can be both client and server side. For server side storage Kore providers wrappers over
libpq to allow async database operations.
It is pretty easy to combine Kore with several other C libraries such as
libev to get a full functional async state machine powering your APIs.
The framework has built-in workers support but I don’t have any performance information yet. Probably I will end up doing the measurements myself.
So I think I really see some potential for it and so I am building a service called Servo to tinker with Kore more intimately and see for myself. I will write more about it when it is mature enough to showcase a demo with it.