Re^3: Another prediction of Perl's demise

The only difference between mod_cgi and mod_perl/mod_php is what level the CGI interface is decoded at. The browser itself sends the same data no matter what.

Under mod_cgi, the server guarentees certain environment variables and how the standard filehandles are setup. The server might modify the output headers slightly (though it definately won't under NPH).

Under mod_perl/mod_php, the server has already done much of the work of deparsing the browser's request, and may significantly alter the output before the response finally goes back. With mod_perl2, the potential for output-munging is even greater with the use of filters that are applied after the CGI or main handler has run.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Comment on Re^3: Another prediction of Perl's demise

Replies are listed 'Best First'.
Re^4: Another prediction of Perl's demise by ikegami (Patriarch) on Nov 26, 2004 at 18:57 UTC
Are you confusing HTTP with CGI? CGI is a specification allowing communication of a HTTP request and a HTTP response between two programs by means of a combination of environment variables, STDIN, STDOUT and STDERR. mod_perl doesn't set or use those env vars, and I doubt that mod_php does, so neither use CGI at all.	[reply]
Re^5: Another prediction of Perl's demise by hardburn (Abbot) on Nov 26, 2004 at 19:54 UTC
mod_perl doesn't set or use those env vars Not for handlers, no. It does when you run Perl code through the perl-script handler. Also, the standard filehandles are never directly connected to the browser, though you can usually pretend they are. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]