I don’t get the association of Gemini protocol and CGI. CGI seems like a rather weird tech.

👤 travisshears

2025-10-15 · 7 months ago · 🤔 1

10 Comments ↓

🌆 skyjake [...] · 2025-10-16 at 03:11:

Well, they aren't strictly associated at all. CGI occurs on server-side as part of processing a request. The Gemini-specific aspect is that some of the CGI environment variables have Gemini-related values. The CGI executable may also be expected to begin its output with a Gemini header line (status code and meta text, followed by CR LF).

Gemini-CGI isn't that well-specified, so you'll need to check a particular server's documentation to see the specifics.

🛰️ lufte · 2025-10-16 at 03:13:

It is a well-established spec for producing dynamic content on the web, it fits perfectly for gemini as well. What do you find weird about it?

👤 travisshears [OP] · 2025-10-16 at 08:29:

Thanks for the replies. “Weird” was bad wording. Having dug deeper now, I think I just prefer application server architecture more for writing Gemini backends.

📻 Christopher · 2025-10-16 at 23:20:

I've implemented CGI support in a Gopher server, and the biggest mismatch I found was that the CGI spec requires a script to respond with headers, which Gopher doesn't have. Then again, the CGI spec also allows for NPH (Non Parsed Header) scripts which means the response is sent directly and unmodified back to the client, which fits Gopher.

But as @skyjake mentions, a Gemini CGI would have to return a response header, but with how simple a Gemini response is, it's pretty straightforward.

🛰️ lufte · 2025-10-22 at 22:35:

@travisshears could you elaborate on that application server architecture?

👤 travisshears [OP] · 2025-10-24 at 10:27:

Hey @lufte sure. By application server arch I mean the basic arch followed by all modern server backends. Flask, express, rails.. They all maintain persistent processes and avoid the process-per-request overhead of CGI. They don't responde to requests by executing shell scripts...

🛰️ lufte · 2025-10-31 at 18:38:

Ah, fair enough, you're technically correct (the best kind of correct) in that the approach followed by modern app servers is not strictly CGI as the spec requires that each request is processed by a separate process. I just put all the newer alternatives under the "CGI umbrella" as they are all so similar, but after closer inspection that also may not be true. It's just that kind of thing you usually don't have to deal with as it just works®, but yeah, I get what you mean.

📻 Christopher · Dec 10 at 20:18:

avoid the process-per-request overhead of CGI

Yes, CGI has overhead launching a process for each request, however it can still be fast enough for many uses. In fact it takes about the same amount of time to launch a program in Linux as it takes to create a thread in Windows (both in the low 10s of µs):

— Benchmarking OS primitives

Meanwhile it takes Windows in the 100s or 1000s of µs to launch a program, so you'll definitely want to avoid using CGI on Windows. Actually, just make that "avoid using Windows". (Even a Raspberry Pi3 is faster than Windows at launching a program except when all indexing and anti-virus services are disabled, and then Windows is barely faster than the RasPi.)

So unless you expect to serve >1k requests per second, CGI is just fine (except maybe in Windows). To give you some perspective, the busiest Gopher server according to

— Gophernicus server uptime leaderboard

is at sdf.org with 14k requests per day. That comes out to a measly 0.16 req/s. I don't have comparable figures for Gemini, but even if Geminispace were 10x the size of Gopherspace, the busiest Gemini server would maybe serve about 1.6 req/s. But most (say, 90%) of those would likely be static files. You're really not in danger of noticing those 300 milliseconds of overhead per day from using CGI (minus (edit: versus) whatever non-zero amount of request overhead an application server adds for the equivalent work).

🌆 skyjake [...] · Dec 11 at 08:22:

I checked the request log for my Gemini server that hosts BBS, Cosmos, and skyjake.fi:

This wouldn't be too bad for plain CGI.

Of course, the maximum was twice that (on November 11th):

(Cosmos does use regular CGI while BBS is a server extension plugin that runs multithreaded in the server process(es).)

📻 Christopher · Dec 11 at 19:17:

63.2k requests

Assuming all of those requests run a CGI and that CGI overhead is 20 µs per call, that's overhead of 1.264 seconds over the whole day, or about 0.00146%. I think I could live with that.