Nginx-CGI Brings Support for CGI to Nginx and Angie
Original: Nginx-CGI brings support for CGI to Nginx and angie
Key topics
The revelation that eBay's old URLs were powered by a DLL file sparks a lively debate about the merits of exposing file structures in URLs. Some commenters scratch their heads over why this was ever done, while others point out that it's simply a matter of mapping URLs to filesystem resources - although others counter that rewrite rules have long allowed for more flexibility. As one commenter quips, "cool URLs don't change," which may be why eBay kept their URLs intact even after switching from IIS to a new frontend. Meanwhile, alternative approaches like OpenResty + Lua get a nod from some as a more modern and elegant solution.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
1h
Peak period
15
0-6h
Avg / period
6.6
Based on 33 loaded comments
Key moments
- 01Story posted
Aug 29, 2025 at 7:40 PM EDT
4 months ago
Step 01 - 02First comment
Aug 29, 2025 at 8:56 PM EDT
1h after posting
Step 02 - 03Peak activity
15 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 31, 2025 at 10:45 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The eBay example, by the way, is ISAPI, not CGI.
3.3M LoC C++, that must have been quite painful.
Today we've removed a lot of SFINAE magic since if-constexpr that is easier to read/trace and also the existence of CONCEPTS to pre-constrain to compatible types and thus avoiding implementation details from becoming the error.
I had some fun between HP-UX aC, AIX xlC, Solaris cc, and Red-Hat gcc, and naturally there was MSVC as well.
We had #ifdefs in place for prototypes, because the version of the aC compiler we had on our development server still only supported K&R C function definitions.
Likewise with ASP.NET on Windows land, as ASP with VB, and C++ alongside COM wasn't that great either.
[0] - By the time this started to matter Java 1.3 was already the common version.
I also used to ask myself why they would expose the filename of the DLL.
I got to know, because I wrote a complete proxy on top of ISAPI, with callback handlers that could be written in C or Tcl.
On Windows NT and 2000, for our application server based on top of IIS (we had a version on top of Apache as well).
But by then ebay wouldn’t be using ISAPI :)
Thus, there's no absolute rule that serving a static state must faithfully map to filesystem representation except convenience. Nor, do dynamic requests need to map to include the details of dynamic handler URIs unless the application cannot change generated links.
Revealing backend state, while somewhat Security Through Obscurity (STO)(TM), it's unwise to volunteer extraneous information without a purpose. Preferably, some other simple, one-way hash external representation should be used.
I played client-side Netscape JS and Apache HTTPd CGI bash shell scripts (not even Perl) to write a toy multiuser chat app in 1996. IIRC, it used a primitive form of long polling where it kept an HTTP/0.9 session open with keepalive commands periodically and then broadcasted the message received to all other users who were also connected.
I also went through quite a bit of effort to make sure _my_ links don't break. There are a handful of tools (like a dig wrapper for DNS lookups) which still can be reached as /cgi-bin/dig.cgi, even though they haven't been a standalone CGI script for two decades now. It's still technically CGI (just running as fastcgi nowadays), and the code base is just as good as you'd expect from what started as an experiment to see how much of a text markup parser I can write using perl regexp only.
OpenResty is a platform with multiple advantages. It's fast (Nginx), it's async via stackless coroutines (no function coloring), it's again fast (LuaJIT), it's relatively easy to deploy, it's feature-rich (all the Lua packages available), and it integrates well with some other tech like Redis (also Lua-enabled).
On the other hand, Lua is an extension language. It's not designed to support large codebases. You can, of course, with enough discipline, make it work - just as you can, with enough grit, make Perl, JavaScript, Ruby, or older Python work, but you're on your own then. You need to invent your own code organization scheme and adhere to it religiously. You need to reinvent half of the stdlib that Python provides out of the box. The reinventing process extends to the need to create a set of helpers to define classes and inheritance between them, which are only provided as powerful but inconvenient primitives (metatables) in Lua.
It's incredible how much you can do with just 100 sloc in OpenRESTY - it's absolutely amazing as a component of a larger system. However, writing lengthy, uninspiring, yet complicated business logic in Lua under OpenResty is not a good idea.
The Web development I'd done up to that point consisted of raw HTML/CSS, with some ASP.NET or PHP running on the backend. I'd never written a line of JavaScript in my life.
It was at this point that I "discovered" a winning combination: HTML, CSS, and JavaScript running in the user's browser. The backend was a set of C# applications which wrote to standard out, which could be invoked directly by Apache's mod_cgi, since C# compiles down to Windows executables. There were countless better other solutions at this point - ASP.NET/PHP (as I'd already used). FastCGI, WSGI, and others were all a thing at this point, but I'd never heard of them.
I outputted a JavaScript object (I had no idea what JSON was at the time, or that I was effectively outputting it) and read it back into the browser using a thin wrapper around XMLHttpRequest. I then iterated over the outputm and transformed the data into tables. JQuery was a thing at that point, but likewise, I'd never heard of it.
Say what you will about the job, the team, the mentorship (or lack theorof) - it took them three months before they realized I'd written C# at a Java shop, and at that point the thing was already being used widely across engineering.
The important takeaway here was, that "winning combination" of some minimal JavaScript and CGI was the perfect ratio of simple, approachable, and powerful, to enable me to finish the task at hand, and in a way that (at least until anybody saw the architecture) everybody was thrilled with. It didn't require a deeper understanding of a framework to bootstrap it from nothing. Write an HTTP response to standard out, formatted as an object, and you were on your way.
Edit: nvm. It looks like it’s just easier to configure.
3 more comments available on Hacker News