NSAPI:
https://en.wikipedia.org/wiki/Netscape_Server_Application_Pr...
NPAPI:
https://en.wikipedia.org/wiki/NPAPI
FWIW, here's some feedback I wrote up and sent to Netscape about the original version of the Netscape plug-in API (NPAPI), when I worked at Kaleida. This was from around 1995, when JavaScript was called LiveScript, before anything like LiveConnect/XPConnect/NPRuntime existed, when Netscape though Java was the solution to all their problems, and before ActiveX of course (but I warned them about Microsoft's use of OLE in the browser), so plug-ins only had very limited if any interaction with LiveScript and DOM.
ScriptX was a multimedia scripting language, a lot like object oriented Lisp or Python with built-in graphics and multimedia libraries. But unfortunately it was not designed to be an extension language library that could plug into another application like Netscape, the way Python does so well. So I made a "ScriptX Plug-Out" that integrated ScriptX running in another process with a Netscape plug-in via Apple Events.
https://donhopkins.com/home/archive/netscape/Netscape-Plugin...
>I hope NetScape can come up with a plug-in interface that is good enough that they can implement their own navigator components with it (like the mail reader, outliner, progressive jpeg viewer, etc). The only way it's going to go anywhere is if they work closely with developers, and use the plug-in interface for non-trivial things themselves. Microsoft already has a VRML plug-in for their navigator, so presumably they have a plug-in interface, and from what I've seen on their web site, it may not be "good enough", but it's probably going to do a lot more that you can do with NetScape right now, since they're exposing a lot of their navigator's functionality through OLE. They seem to understand that there's a much bigger picture, and that the problems aren't trivial. Java isn't going to magically solve all those problems, folks.
I used mod_perl extensively in the summer (May-Aug) of 1996; it was the only way I found to embed perl directly into the server process, at the time.
We had a clunky CGI script that crawled the filesystem on request, no doubt a security hole waiting to happen, but Netscape made it worse. (It's possible that other web servers did, or even still do, but I really hope not.)
Anything that the script sent to standard error, which could reveal things like filesystem paths and other sensitive data, was not only logged, but also fed back to the web client as part of the response.
Luckily, because stderr wasn't buffered, in our case it was fed to the browser before any headers, causing the web client to throw up a server error instead of displaying the error messages themselves.