Kcgi: A Minimal CGI and FastCGI Library for C/C++

In an era where web development is dominated by high-level frameworks, writing web applications in C sounds like some kind of performance art. But if what you need is extreme performance, minimal dependencies, or to maintain an HTTP server running on an embedded device, a library like Kcgi might actually be the most pragmatic choice.

What Is Kcgi

Kcgi is a minimal CGI and FastCGI library written in C, developed and maintained by Kristaps Dzonsons and released under the ISC license. The library's design goal is very clear: to provide C/C++ developers with a lightweight toolkit for building dynamic web applications.

The name says it all—"minimal." Kcgi doesn't try to be yet another web framework. It does one thing: parse HTTP requests into programmer-friendly data structures and help send responses back to the client. No ORM, no template engine, no routing middleware. The rest is entirely in your hands, in C.

Core Design Philosophy

Kcgi's API is built around a set of concise functions. Developers use khttp_parse to parse requests, traverse the kreq structure to retrieve GET parameters, POST form data, cookies, and HTTP headers, then call khttp_head and khttp_body to construct responses. The entire process requires no global state and no complex initialization procedures.

This design is quite friendly to programmers who are familiar with C but not with web development. It encapsulates the error-prone details of web protocols—such as URL encoding/decoding, multipart form parsing, and character set handling—internally, exposing interfaces that conform to C conventions. You don't need to worry about the details of chunked transfer encoding in the HTTP/1.1 specification; you just tell Kcgi what you want to output.

The Significance of FastCGI Support

CGI, as a product of the last century, has its biggest problem in that each request requires starting a new process. Under high-concurrency scenarios, this overhead is unacceptable. FastCGI was created precisely to solve this problem—it keeps the application process resident, allowing the web server to forward requests to the application via socket.

Kcgi's FastCGI support means you can deploy it behind Nginx or Apache and write long-running web services in C. For scenarios that need to handle large numbers of concurrent connections but don't want to introduce a full web framework—such as API gateways, simple REST services, or static file servers—this combination can deliver quite solid performance.

CGI (Common Gateway Interface) is the earliest server-side dynamic content standard, born in 1993 alongside NCSA HTTPd. Its working method is very direct: after receiving a request, the web server forks a new process to execute the specified executable, passing request data through environment variables (such as QUERY_STRING and REQUEST_METHOD) and standard input, then reading the returned HTTP response through standard output. The advantage of this model is that it's language-agnostic and protocol-simple—any program that can read and write standard input/output can serve as a CGI script. The downside is that the overhead of process creation, memory initialization, and interpreter startup must be paid repeatedly with every request. As concurrency rises, CPU and memory are heavily consumed by process management rather than actual business logic. This is precisely the fundamental motivation behind the invention of FastCGI.

FastCGI was proposed by Open Market in 1996. Its core idea is to change CGI's "one process per request" to a "resident process pool + socket communication." After startup, the application runs as a long-lived daemon listening on a Unix domain socket or TCP port. The web server (Nginx via fastcgi_pass, Apache via mod_fcgid or mod_proxy_fcgi) writes requests to this socket in FastCGI protocol format, and the application writes responses back after processing. The protocol itself defines record types such as FCGI_BEGIN_REQUEST, FCGI_STDIN, FCGI_STDOUT, and FCGI_END_REQUEST, and supports multiplexing, allowing multiple requests to be processed concurrently over a single connection. Compared to CGI, FastCGI eliminates the overhead of repeated forking, offers low startup cost and good scalability, while preserving the stability brought by process isolation—a crash in one request won't bring down the entire server. Kcgi encapsulates this FastCGI protocol inside the library, so C developers only need to handle already-parsed request structures.

Suitable Use Cases

Kcgi isn't for everyone. If you're building a modern web application with user management, database interactions, and complex business logic, using Go, Rust, or Node.js is clearly more reasonable. But if you're facing the following scenarios, Kcgi is worth serious consideration:

Embedded systems. On resource-constrained devices, every byte and every megabyte of memory is precious. Kcgi plus libevent or a similar lightweight networking library can build an HTTP server with a tiny footprint.

Performance-sensitive internal tools. When you need a simple status monitoring page or admin interface but don't want to deploy a separate runtime environment for it, writing a few dozen lines of C with Kcgi and compiling it into a single binary means deployment costs are almost zero.

Learning the low-level mechanics of the HTTP protocol. Kcgi's source code itself is excellent teaching material for understanding how CGI and FastCGI work. There are no layers of abstraction; after reading the source, you can clearly see the complete path from socket to HTTP response.

libevent is a high-performance event notification library written in C, developed by Nick Mathewson and Niels Provos, and is one of the underlying dependencies of well-known projects such as Memcached, Tor, and Chromium. It abstracts away the differences in I/O multiplexing across operating systems: it wraps epoll on Linux, kqueue on BSD/macOS, uses /dev/poll or event ports on Solaris, and select or IOCP on Windows, exposing a unified event_base event loop interface. Developers only need to register read/write event callbacks on file descriptors; scheduling, timeout management, and signal handling are all handled by libevent. In Kcgi usage scenarios, libevent typically plays two roles: first, as the event loop for the FastCGI listening socket, allowing a single process to accept multiple connections simultaneously; second, in embedded or self-built server scenarios, directly providing HTTP listening capability that works with Kcgi's request parsing functions to form a standalone HTTP service independent of Nginx. Compared to similar libraries like glib and libuv, libevent has a longer history, a smaller footprint, and better support for older platforms and cross-compilation, which is why it frequently appears in embedded C projects.

Community Perspective

The discussion Kcgi sparked on Hacker News reflects an interesting phenomenon: even today, when high-level languages and frameworks dominate, a considerable number of developers still insist on using C for web development. Their reasons are often not performance, but control—complete control over memory layout, dependency chains, and deployment complexity.

This preference may never become mainstream, but it represents an engineering choice worthy of respect. In an era of increasingly complex technology selection, a library like Kcgi that focuses on doing one thing well stands out as remarkably clear.

One-line Summary

Kcgi is an ISC-licensed minimal C CGI/FastCGI library focused on HTTP parsing and responses, ideal for embedded and high-performance scenarios.

Paragraph Summary

Kcgi is a minimal CGI and FastCGI library developed by Kristaps Dzonsons under the ISC license, designed for C/C++ developers building dynamic web applications. It provides no ORM, template engine, or routing middleware—it only parses HTTP requests into a kreq structure, encapsulates error-prone details like URL decoding and form parsing, and organizes responses through khttp_head and khttp_body, leaving everything else entirely in the developer's C-controlled hands. FastCGI support allows it to be deployed behind Nginx or Apache as a resident service, avoiding the per-request process overhead of CGI, making it suitable for API gateways, simple REST services, and similar scenarios. The article argues that Kcgi is not suited for complex modern web applications, but holds unique value in three areas: embedded systems, performance-sensitive internal tools, and learning the low-level mechanics of HTTP. Its Hacker News discussion also reflects some developers' insistence on control and deployment simplicity.