13 posts tagged “cgi”
2025
Serving 200 million requests per day with a cgi-bin (via) Jake Gold tests how well 90s-era CGI works today, using a Go + SQLite CGI program running on a 16-thread AMD 3700X.
Using CGI on modest hardware, it’s possible to serve 2400+ requests per second or 200M+ requests per day.
I got my start in web development with CGI back in the late 1990s - I was a huge fan of NewsPro, which was effectively a weblog system before anyone knew what a weblog was.
CGI works by starting, executing and terminating a process for every incoming request. The nascent web community quickly learned that this was a bad idea, and invented technologies like PHP and FastCGI to help avoid that extra overhead and keep code resident in-memory instead.
This lesson ended up baked into my brain, and I spent the next twenty years convinced that you should never execute a full process as part of serving a web page.
Of course, computers in those two decades got a lot faster. I finally overcame that twenty-year core belief in 2020, when I built datasette-ripgrep, a Datasette plugin that shells out to the lightning fast ripgrep CLI tool (written in Rust) to execute searches. It worked great!
As was pointed out on Hacker News, part of CGI's problem back then was that we were writing web scripts in languages like Perl, Python and Java which had not been designed for lightning fast startup speeds. Using Go and Rust today helps make CGI-style requests a whole lot more effective.
Jake notes that CGI-style request handling is actually a great way to take advantage of multiple CPU cores:
These days, we have servers with 384 CPU threads. Even a small VM can have 16 CPUs. The CPUs and memory are much faster as well.
Most importantly, CGI programs, because they run as separate processes, are excellent at taking advantage of many CPUs!
Maybe we should start coding web applications like it's 1998, albeit with Go and Rust!
To clarify, I don't think most people should do this. I just think it's interesting that it's not as bad an idea as it was ~25 years ago.
2019
websocketd (via) Delightfully clever piece of design: “It’s like CGI, twenty years later, for WebSockets”. Simply run “websocketd --port=8080 my-program” and it will start up a WebSocket server on port 8080 and fire up a new process running your script every time it sees a new WebSocket connection. Standard in and standard out are automatically hooked up to the socket connection. Since it spawns a new process per connection this won’t work well with thousands of connections but for smaller scale projects it’s an excellent addition to the toolbok—and since it’s written in Go there are pre-compiled binaries available for almost everything.
2013
Are there any alternatives to CGI for web servers?
Yes. CGI stopped being relevant around the turn if the century! Many languages can be embedded in web servers now (mod_php, mod_python, mod_perl for Apache etc), there’s the FastCGI protocol which allows web servers to communicate with external processes without needing to start a brand new process for every request, and it’s also common these days to run an HTTP server written in the same language as your application and proxy requests to it—Unicorn, gunicorn, Jetty are all examples of this.
[... 98 words]2008
sfical.py. Neat idea: write a CGI script that turns a proprietary API (in this case the SalesForce events API) in to standard ical format, then run it on your Mac’s local Apache server and subscribe to it from iCal.
2007
.php? .cgi? .who-cares? J-P Stacey argues that “URLs need to be hackable by the developer as well as by the user”. There’s certainly room for improvement in keeping complex URL structures maintainable from a server-side developer’s perspective.
2006
2004
Apache Module mod_actions. Channel all requests for a specific file type through a CGI script.
Pwyky (A Python Wiki) (via) A neat little wiki in a single CGI file
2003
cgi_buffer
cgi_buffer is voodoo magic for Perl, Python and PHP scripts that automatically handles a bunch of bandwidth saving HTTP tricks such as Content-Length headers (which enable persistent connections), ETags for caching and GZip content compression. Pretty neat.
The difference between POST and GET
How important is the ability to tell the difference between data sent by POST and data sent by GET (i.e in the query string) when developing web applications? Some web frameworks (such as PHP) provide separate mechanisms for accessing POST and GET data. Others (such as Python’s cgi module) provide a single interface to form information that doesn’t distinguish between the two. I already have a strong opinion on this but I’m going to leave it open for discussion here for a bit before weighing in.
The Python Web SIG
Python now has a Web SIG. SIGs are Special Interest Groups, each with a target to develop and improve a certain aspect of the Python language, standard library or community. The Web SIG has two purposes: create a plan for improving Python’s web client abilities (including things like the ability to parse CSS) and work on improving Python’s server side capabilities.
[... 289 words]Ludicrously simple templates with Python
A long, long time ago I wrote my first ever PHP templating system. It was pretty simple; it consisted of a function that took two arguments: the name of a template file, and an associative array of replacements to make on that file.
[... 251 words]2002
More Python advocacy
More Python advocacy: PYTHON: Yes, You SHOULD Be Using it! The article contains some background information on Python and why it is worth knowing, but the bulk of the article consists of a getting started guide for Python on Linux, complete instructions on using the interactive prompt, code samples and a small CGI script. It is worth noting that the CGI script example should not be deployed anywhere accessible to the public as it could allow crackers to execute code of their chosing on your web server.