3 ms·
The elegance of CGI was in generically plumbing HTTP requests through to the standard unix environment whilst facilitating arbitrary server metadata. The reason
by contingencies 3y ago
The elegance of CGI was in generically plumbing HTTP requests through to the standard unix environment whilst facilitating arbitrary server metadata. The reason it fell out of fashion was partly the objective limitations of speed, security, and no standard method of debugging, but probably also largely because of a generational shift toward interpreted languages written by new developers largely based on and used to non-unix style systems who quite pragmatically saw the server environment as a black box and were consequently motivated to use simpler and more standard environments such as that provided by php and its extensions in lieu of tediously manually configuring every server path in every script via telnet (and later ssh). Their ISPs and web hosts, aware of the security challenges of granting unix shells to inexperienced users, encouraged this and consequently embraced tooling such as cPanel to reduce the support load for their staff and spin up users faster.
Having cPanel-style user instantiation and management functions then became more and more critical as IP addresses ran out and virtual hosting took hold - the amount of manual config tweaking otherwise required (vhost, database, filesystem, (s)ftp access, etc.) exceeded a rational human workload for medium sized service providers, especially those with large numbers of users spread across an array of non-uniform infrastructure.
By the time the 'cloud' arrived, this stuff at typical ISPs and web hosts had become a mish-mash of band-aids so advanced that in hindsight we might well wonder why it took so damn long for the paradigm to shift.
- mgaunard 3y agoCGI offered much better security than the alternatives that replaced it.
- synergy20 3y agohow?CGI runs with the same permissions as http server,if you need run privileged operations you have to let it sudo.. fastcgi is safer
- mgaunard 3y agoIt runs in a separate process, and is therefore isolated from the HTTP server. Making it run as the owner of the file is also quite common and trivially achieved (suExec). mod_php, on the other hand, runs inside the HTTP server process and with the same uid and capabilities, with no way to change that.
- tlavoie 3y agoPersistent servers moved the goal-posts for problems at least. With stateless HTTP, maintaining state somewhere was always part of the challenge, so CGI programmers would be tempted to put too much into client-side cookies. That meant the user could see and tamper with that info. On the other hand, the brief existence of that CGI program meant that the OS cleaned up much of what the programmer may not have.
- contingencies 3y agoMany of us that old remember independently implementing session engines before they were standard features in the various web-oriented languages of the era (mostly perl and php)... this solved the issue of trusted client-side state by isolating the shared secret to a session identifier and storing real state server side, usually in a file or database. Naïve implementations did not, however, solve for issues such as locking, enforced sequencing for multi-stage actions, token loss, or multiple sessions or clients under an individual account, leading to a plethora of web engine state related bugs, some of which probably re-emerge to this day in novel and embedded session engines.