|
|
|
|
|
by tyingq
1734 days ago
|
|
On passing environment variables instead of the full request, probably to make it more accessible to get started with the existing popular languages (C, Perl, Tcl, Shell Scripts, mostly) without having to write all the request parsing. There was also less "stuff" in the request than today. No cookies, no file uploads, and so on. They also passed things in that weren't in the request itself, like REMOTE_ADDR, REMOTE_HOST, SERVER_PORT, PATH_INFO and so on. So it seemed natural to just put everything in environment variables, other than the $CONTENT_LENGTH bytes that followed the header. As for the fork() per request, I believe mostly because they were starting with requirements where avoiding fork() wasn't important. Conserving memory was probably more important, given the timeframe. CGI programs that leaked memory would have been common if they were daemons. For most web servers, there also probably weren't that many requests. It was also a common existing pattern. Many of the services on unix boxes worked the same way...one daemon (inetd) would start instances of daemons per request and they would serve only one request. That said, NSAPI appeared pretty quickly after CGI, then FastCGI, etc. Still pushing environment variables for headers, but stopping the request->fork->exit pattern and allowing persistent daemons. |
|