[HN Gopher] 1993: CGI Scripts and Early Server-Side Web Programming
___________________________________________________________________
1993: CGI Scripts and Early Server-Side Web Programming
Author : tmfi
Score : 111 points
Date : 2021-03-25 16:18 UTC (6 hours ago)
(HTM) web link (webdevelopmenthistory.com)
(TXT) w3m dump (webdevelopmenthistory.com)
| marsrover wrote:
| Actually writing CGI scripts was a bit before my time, but I have
| very fond memories of installing and using Newspro and Imagefolio
| on my old web pages.
| girishso wrote:
| The linksys WiFi router I was using until last year used cgi app
| for the admin interface.
|
| My first web application was developed in 1999 in IISAPI (VC++)
| running obviously on IIS. I had to write a rudimentary session
| storage (in plain txt file!), because it was not provided by the
| framework.
| bitexploder wrote:
| We do a lot of assessments of embedded devices and a surprising
| amount of them still have compiled C programs and CGI for their
| web interfaces.
| blhack wrote:
| "CGI is still a useful web programming paradigm" is a hill I am
| prepared to die on.
| HeyLaughingBoy wrote:
| Am I the only one here who remembers _Philip and Alex 's Guide to
| Web Publishing_? https://philip.greenspun.com/panda/
|
| OK, looks like my memory isn't that good. panda came out in 1998.
| At the time I was working for a company that paid Y2K bonuses to
| dissuade us from quitting and moving to the Bay Area. I often
| wonder how different my life would be if I had done that.
|
| Who am I kidding? I was having way too much fun writing motion
| control software to do any of that Web crap ;-)
| j4yav wrote:
| CGI was a wonderful paradigm for when I was first learning web
| development, a few years after this. A shell account somewhere,
| some scripts that just had to deal with stdin and stdout, and you
| could create amazing web experiences. Previously I only knew
| BASIC, but CGI let me start to share my weird little creations
| with the world.
|
| There should be more simple ways for young people to write and
| share programs with each other. Maybe that's what Roblox is, to
| an extent? I haven't used it myself.
| incanus77 wrote:
| When I got to college and got online in 1995, I pretty quickly
| learned about CGI scripts and the cgi-bin directory, which of
| course my school did not have enabled on campus-wide accounts
| (security risks). I really wanted cool stuff like a web hit
| counter on my page. A lot of web hosts at the time would
| advertise something like "5MB of space and your own cgi-bin!" and
| I eventually got to one of these, got into Perl, and start making
| stuff using Berkeley DB and other on-disk databases. Eventually I
| outgrew this, found PHP & MySQL, found a web host who supported
| it, went to work at that web host, ... All said, CGI's were
| totally the reason I got into internet programming.
| tyingq wrote:
| I do have fond memories of the simplicity of CGI, but also
| remember the big speedup and scalability improvement when we
| swapped over to NSAPI (no more forking, pooled processes, etc).
|
| Kind of interesting that "serverless" (AWS Lambda, etc) seems to
| be going through the same evolution now. That is, initially
| liking the simplicity then hitting a wall with performance and
| making it more complicated.
| tpmx wrote:
| FastCGI was the standardized approach.
|
| See also: https://news.ycombinator.com/item?id=24683304
| ("FastCGI - The Forgotten Treasure (2002)")
| tyingq wrote:
| Sure. Wikipedia mentions FastCGI initially being a reaction
| to NSAPI.
|
| _" Open Market originally developed FastCGI in part as a
| competitive response to Netscape's proprietary, in-process
| application programming interfaces (APIs) (Netscape Server
| Application Programming Interface (NSAPI)) for developing Web
| applications"_
| tpmx wrote:
| Oh, I'm showing my ignorance here - I didn't know NSAPI was
| in-process. The Netscape server software was expensive and
| kinda hard to find in Europe back then. I guess FastCGI was
| an improvement in terms of stability - I'm assuming the
| NSAPI was .so/.dll-based? So if you messed up, the entire
| server went down.
|
| Back in the mid 90s I worked on the Spinner/Roxen webserver
| that was built on an interpreted C-like language modelled
| after the LPC language being used for MUDs. Modules were
| were run in-process, but because of the interpretation a
| failure resulted in an exception/error, rather than a full
| crash. This software didn't get very popular - we sucked at
| marketing.
| tyingq wrote:
| Most people kept the in-process stuff down to something
| that worked like Fast-CGI, just proxying requests to some
| non-NSAPI persistent process over a socket.
| tpmx wrote:
| Somehow this ended up at Oracle? That's just nasty.
|
| https://docs.oracle.com/cd/E19146-01/821-1833/index.html
| tyingq wrote:
| Yes. Sun/Netscape co-owned the iPlanet brand and
| products, Oracle bought Sun. AOL still has iPlanet rights
| though, so it's actually in two places.
|
| Tricky to follow where all the stuff ended up:
| https://en.wikipedia.org/wiki/IPlanet
| [deleted]
| jandrese wrote:
| I still think Lambda was just CGI tarted up and sold as a whole
| new thing.
|
| There was a transition period where people were trying to still
| use CGI but make it scale so you had things like CGI mod_perl
| in Apache.
| tyingq wrote:
| Ah, yeah...mod_perl did make a nice bridge for Perl stuff. I
| had mentioned NSAPI because we had C++ CGI and NSAPI was
| available before things like FastCGI.
| Nursie wrote:
| Been thinking this recently, lambda is a return to CGI, you
| provide a small program that runs and provides its results to
| something which sends them back to the client.
| tyingq wrote:
| And you similarly worry about things like cold starts :)
| _wldu wrote:
| Unless your lambda was written in Go.
| tyingq wrote:
| Maybe. ~300ms floor isn't terrific for some use cases,
| and could be higher if you need an ENI, etc.
| jeffbee wrote:
| One of the best aspects of CGI is how easily tested a CGI program
| is. All you have to do is set a couple environment variables and
| connect your request entity to stdin, expecting things on stdout.
| What could be better?
| marianov wrote:
| I remember creating a web query form for an employee search or
| something like that using CA Clipper and reading stdin an
| spitting our HTML on stdout. Worked like a charm, was fast and
| made that data available to whoever needed it.
| augusto-moura wrote:
| The best FAAS framework
| hatch_q wrote:
| Was also easy to "verify" contents of /etc/passwd and
| /etc/shadow. _cough_ cgi-bin /phf _cough_
| tn1 wrote:
| That's not the fault of CGI but rather of the people who
| wrote bad code. You can easily have the same problem in your
| NodeJS express app if you're careless!
| _greim_ wrote:
| In the early 2000s, Sun's patching support website, sunsolve, was
| a massive Apache/CGI empire. Perf. problems were rife and by
| early 2002 the whole thing was grinding to a halt under traffic.
|
| It just happened to be intern season. In walks some fresh-faced
| kid and installs mod_perl. Like magic, the entire website stands
| up, dusts itself off and starts working again. CPU load drops by
| two thirds. I think the senior engineers were kind of pissed but
| couldn't really say anything. I think the kid got a beer or two
| out of the whole thing. (And of course got an offer to stay.)
| xrd wrote:
| I used Lincoln Stein's CGI.pm module
| (https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#CGI.pm...)
| all the time back then. I wrote a Perl module for SMIL which I
| called SMIL.pm and emailed him to tell him and was thrilled when
| he responded. I'm strangely saddened to hear it has been removed
| from Perl.
| tacostakohashi wrote:
| You must be a latecomer to the scene... "back then", people
| used cgi-lib.pl:
|
| https://cgi-lib.berkeley.edu/
| eCa wrote:
| It's still available[1] (and maintained) for those that need
| it, but there are much better tools available for web work
| these days, like Mojolicious and Dancer.
|
| [1] https://metacpan.org/release/CGI
| godot wrote:
| I feel like CGI Perl scripts back in the late 90s was definitely
| a critical reason for me picking up on programming, web dev (as a
| high school kid), and eventually becoming a professional web
| developer, and software engineer.
|
| The whole web dev paradigm back then starting from basic HTML
| files, to client JS, to server-side Perl CGI scripts, was just
| really easy to wrap my head around, and actually create usable
| products out of. It maps well to a Windows OS file system -- you
| have these HTML files sitting in folders, you can write them
| locally and open them locally to see them. Upload to a server via
| FTP in the exact same structure, and see it work on the internet.
| If some files are CGI scripts, they run some code on server
| before output. Input from browser comes in as stdin in the
| script, and output to browser is just stdout. It was simple
| enough that as a high school kid, I was able to start one of
| those "webmaster services" (providing guestbooks, counters,
| etc.). I have nothing but fond memories building scrappy stuff
| back in those days.
| musingsole wrote:
| With that perspective, what are your thoughts on the modern
| ecosystem?
| ed_blackburn wrote:
| I recall writing CGI scripts in perl. I met some guys are work
| that used C and I was shocked. But not as shocked as my boss. It
| took them so long to deliver applications compared to cranking
| out perl.
| tannhaeuser wrote:
| Sure, that's also how PHP started. Thing is, with Perl and PHP,
| before mod_perl and mod_php, your script needed to be parsed
| for every single uncached request, easily dominating everything
| else, like URL parsing and process creation time. Hence
| natively compiled CGIs weren't such a bad idea. They're even
| used today a lot, with Apache/CGI uptimes measured in decades
| since neither Apache nor CGI binary updates require planned
| downtime on Unix. Its ultra-robustness is one of the reasons
| the concept of FaaS has become fashionable again.
| ksec wrote:
| It wasn't _easy_ , but everything was so much simpler back then.
|
| Modern Web Development are needlessly complicated. Both Front End
| and Back End. Oh... and deployment.
| _wldu wrote:
| Yep. I love Go, but I am certain it would not be half as
| popular as it is were it not for those simple statically linked
| executables that can be deployed anywhere quickly.
| ipunchghosts wrote:
| I remember writing cgi scripts in quickbasic! What a fun time
| that was to be alive.
| Animats wrote:
| FCGI is still quite useful. You can use FCGI, Apache, and Go to
| get quite good performance. FGCI will spin up more Go servers as
| needed, and the Go servers can process multiple transactions
| without reloading the program. Probably outperforms node.js.
|
| Basic CGI reloads the worker program for each request, which is
| secure but slow. FCGI is an orchestration system. Like
| Kubernetes, but with lower labor costs. If one of the workers
| crashes, a new one will be started.
|
| You can run stuff like this on US$10/month shared hosting
| accounts. To scale up, put a load balancer in front and a
| replicated database on the back.
| morelisp wrote:
| Why would you do this instead of just proxy directly to a Go
| server with sufficient GOMAXPROCS?
| threeseed wrote:
| > FCGI is an orchestration system. Like Kubernetes, but with
| lower labor costs
|
| It does about 0.00001% of what Kubernetes can do.
|
| Launching processes to handle web requests is pretty basic for
| any web server.
| at_a_remove wrote:
| I still have cgi scripts running, I assume, somewhere.
|
| Sometimes you just need a single file that does a few things and
| mostly behaves like a webpage. It doesn't need to be deployed or
| managed or anything. I had this one that served approximately
| seven requests on average for over a decade. It's simple. It
| doesn't need any love. It's in the documentation for the overall
| site because I wrote the documentation, but it isn't "omg this
| needs an APP and a BACK END and we have to worry about SCALING."
|
| I still have a book somewhere on CGI with Perl and C, from the
| 1990s. Probably due for a purge.
| maccard wrote:
| My go-to for that now is python -m http.server, with nginx if i
| need anything more complicated.
| at_a_remove wrote:
| I may have to look into it since python is deprecating the
| cgi module, to my _great_ annoyance.
|
| Or maybe not. I seem to have gotten out of the web business
| at the right time. It's gone in a direction that makes me
| grind my teeth.
| _greim_ wrote:
| > In many ways then, it was CGI -- not JavaScript -- that was the
| start of web applications.
|
| "Before we had these nifty LED bulbs, we burned candles."
| forgotmypw17 wrote:
| CGI is in my list of what I consider "core Web technologies", and
| still include and use in my projects.
|
| I haven't written it up yet, but basically it's things which are
| supported by almost every browser and/or almost every web server.
|
| Other things on the list are parts of HTML 3.2, like <p> tags,
| the standard format of access.log, HTTP/1.1, etc.
|
| I try to not use anything outside of that list in my projects,
| some JS things being an exception (which I feature-check before
| using)
| JakeStone wrote:
| Those were interesting times. I think I prefer having a lot of
| things be plug and play now.
| soapdog wrote:
| CGI still work great if you know your constraints and for whom
| you're building stuff. It is underrated alongside its cousins
| FCGI and SCGI. A ton of little tools work great as CGIs.
| layoutIfNeeded wrote:
| Shameless plug: I wrote this small CGI script in bash to serve
| stuff from my home server with auto-expiring links:
| https://github.com/tzahola/share-link
| iso1210 wrote:
| Yes, I have many scripts that I throw an _echo "Content-Type:
| text/html\n\n"_ or _text /plain_ at the top and serve from
| apache. Job done, move on.
| lovelyviking wrote:
| What about security? Is there a _safe enough_ way to still use
| it _today_ ?
| Diederich wrote:
| Sure it can be used safely. Appropriately sanitize inputs,
| don't pass things through the shell, pretty typical stuff.
| fallat wrote:
| If anything no input interpretation should happen,
| everything should just go directly to the program, and the
| program should not be capable of file operations.
| stdin/stdout only.
| throw_away wrote:
| also, taint checking built into the language to enforce
| sanitization: https://en.wikipedia.org/wiki/Taint_checking
| throwaway823882 wrote:
| This feature is one of those things that proves that the
| technology industry is bullshit.
|
| There's an entire industry, probably worth hundreds of
| billions of dollars, built around trying to detect
| insecure code and force it to be less insecure.
| Meanwhile, this one old language that nobody uses has a
| single option you enable to be [more] secure by default.
| And I'll bet you a billion dollars the reason other
| languages don't have it is _" the design doesn't look
| very clean"_.
| midasuni wrote:
| Why wouldn't it be safe? Many scripts I have are only
| available internally so don't need to worry about people
| hacking them (unless they want to risk being fired to look at
| say syslog messages without having to ssh into the box).
|
| Perl -T helps ensure there's no tainting of variables - you
| take the parameter that's passed and regex pull out the
| matching pattern you need to use. If your variable is a match
| of ([\d]+) then it's only going to have numbers in, and you
| can use it fairly safely
| kenniskrag wrote:
| is there a great docu for fcgi? Tried to learn it.
| earthboundkid wrote:
| Did you read the spec https://fast-cgi.github.io? Was that
| not helpful?
| josephscott wrote:
| My first code for CGI was all done in C. When I found Perl, there
| was no looking back, never used C for CGI again.
|
| While I haven't written any significant Perl in a long time, I
| will always appreciate how much it improved things for me back
| then.
| jandrewrogers wrote:
| Same. Wrote a complete database-driven web application in C, an
| online bookstore. Switching to Perl 4 was a _vast_ improvement
| in terms of development productivity.
| mleo wrote:
| Same. My first C cgi program was a small Tic Tac Toe game that
| kept the current state in the request string. It had a little
| logic to play against the user. It did not, however, support
| number of players 0.
| g051051 wrote:
| C-based CGI programs that implemented a web app for doing drop
| shipment of phones to customers. It was supposed to be used for
| just a few months while they waited to roll out a more official
| solution. The users hated the official one, and kept using my
| version for another 4 years.
|
| After that, it was Java all the way.
| brundolf wrote:
| Just thinking about C's story for strings, and trying to use
| that for webpage rendering/input handling/validation...
| [shudder]
| pjmlp wrote:
| Almost same here, I went with Tcl instead.
| macintux wrote:
| Same here. cgic was a useful library for C, but Perl was a
| revelation.
| davidw wrote:
| I got my start doing professional programming working on Perl CGI
| code.
| [deleted]
| cperciva wrote:
| The non-static portions of the Tarsnap website still consists of
| CGI scripts written in C.
|
| Sure, forking a process per request isn't fast... but I'd love to
| have enough traffic for that to matter.
| midasuni wrote:
| There seems to be a general view that anything you write today
| has to scale to a million concurrent users.
|
| There's literally 20 people that have client certificates that
| can access my page. I don't care if they fork a process each.
| zokier wrote:
| Well, AWS kinda has made it so that almost every millisecond
| of CPU time (or other resources) is considered billable.
| While in the olden days you could run some scripts in some
| unused corner of a server for "free", with clouds that is
| less likely.
| ChrisMarshallNY wrote:
| I remember SSI. I haven't seen much of that albatross in ages.
|
| Good riddance.
|
| I did write an entire CMS in PERL, once.
|
| I still wake up screaming...
| ilaksh wrote:
| I have recently been using something very similar to CGI scripts
| on my Jetforce Gemini server. It actually goes in cgi-bin
| although its not exactly CGI. I used it to make an interface to
| Zork.
|
| You can try it out if you have a Gemini client:
| gemini://zork.club
|
| For these types of things I recommend the diohsc client
| https://repo.or.cz/diohsc.git although you may need to build from
| source since he had an issue with Jetforce compatibility and not
| sure if it's fixed in cabal yet.
|
| But any Gemini client will work such as av98 or Lagrange.
|
| The guy who made diohsc set up something a little more
| sophisticated using SCGI and he has several interactive fiction
| on his Gemini server (if it's up). (You can search on gus.guru
| for gemrepl).
| throwaway_dcnt wrote:
| While CGI scripts written in perl and shell script were all the
| rage, I remember using C (and ODBC) quite fondly and
| successfully. It wasn't until I encountered the webscr.cgi at
| PayPal that was more than a GB compiled and spanned millions of
| lines of C language that I realized the error of my ways.
| yabadubakta wrote:
| Yikes, surely you exaggerate the size of a C exe. I guess if
| enough text was baked into the binary?
| toast0 wrote:
| No, that definitely happened. I wasn't there, but I'm pretty
| sure I've seen discussions from multiple companies about how
| they managed when their C based CGI/FCGI/HTTP+logic
| executable got too big to fit in 32-bit memory space; for
| some, amd64 came in time, for others, they had to split
| things out, or do terrible stuff with PAE. Adjusting the
| user/kernel address split was also common, IIRC.
| iso1210 wrote:
| I had no idea what I was doing back then - copying scripts from
| MSA, no idea what chmod or ftp binary mode or even what the unix
| system I was telnetted into was (couple of years before). Managed
| to get things working though.
|
| No mention of server-side includes, which were great -- you could
| include a nav bar on all your pages and just have one file to
| update, you could include a 'last updated' line at the bottom
| based on the file modification, you could include a visitor
| counter.
|
| I did a website for a local art+book shop back in 1997, it was
| awful. Stopped updating it after 6 months, but it was kept online
| for some reason - even after the shop closed. archive.org shows
| the SSI counter was still incrementing in 2005. I assume the
| (copy-and-paste) code ran a script that opened a file,
| incremented the number, wrote it back to the file, then printed
| the number.
| adamrezich wrote:
| Random question but I've often heard people refer to computer
| graphics in movies and television as "CGI" instead of "CG." I've
| always wondered: is this just a weird conflation of terminology
| from an era when Common Gateway Interface was a thing, around the
| same time fancy computer graphics technology was starting to take
| off in the 90s? Or is there there an alternative, legitimate
| reason why one would refer to _C_ omputer _G_ raph*I"cs as "CGI?"
| arkitaip wrote:
| It means Computer-generated imagery.
| adamrezich wrote:
| Oh neat, I had no idea!
| detaro wrote:
| It's for Computer Generated Imagery, not Computer Graphics. And
| it was used in the 80s already, before the web-CGI.
___________________________________________________________________
(page generated 2021-03-25 23:01 UTC)