Hacker News Reader

Comment by tyingq | Hacker News Reader

Server side, so not in Firefox, but I personally got a lot of mileage out of NSAPI. For the company I worked at, at the time, it was the only way to do something better than old-school, fork a process per request, CGI. We had persistent socket processes handling web requests, in parallel, WAY before things like mod_perl or FastCGI. As I remember, it was there around 1995 or so. Many thanks to any former Netscapers. For comparison mod_perl was 1999 or so. FastCGI was really beta and unknown (as I remember) in late 96.

View on HN

NSAPI, the server based Netscape Server Application Programming Interface, is not to be confused with NPAPI, the browser based Netscape Plug-in Application Programming Interface. (I only say that because I just confused them, then realized my mistake.)

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.

> For comparison mod_perl was 1999 or so

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.

Ahh. Okay. My memory was off then. Sounds like mod_perl co-existed with NSAPI.

I have far less fond memories of Netscape Web Server.

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.

Maybe my memory, but that feels more like your problem than theirs. NSAPI was fairly well documented, to the point where stderr was your problem to fix, and documented that way.

Not NSAPI, CGI.

Reply on news.ycombinator.com