ID: 14409 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache related Operating System: IRIX64 vega 6.5 04191225 IP27 PHP Version: 4.2.2 New Comment:
This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. This is fixed for CGI in both the 4.3 tree and HEAD. 4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12 5.0: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.208 Previous Comments: ------------------------------------------------------------------------ [2003-01-21 15:31:33] [EMAIL PROTECTED] I've duplicated this on Linux/Apache w/ PHP 4.3.0 running PHP via CGI. Documents that don't return "No input file specified." and the apache logs show a 200 (succesful page retrieval). Nothing is sent to the error log. The problem is that there's no way to track or log bad page requests. This is very very bad. ------------------------------------------------------------------------ [2002-10-22 02:05:57] [EMAIL PROTECTED] Small addendum. PHP does exit 255 if its target does not exist, but since it has already sent a complete CGI/1.1 HTTP header back to Apache ("Content-type: text/html\n\n"), including the blank line that indicates end of headers, Apache has already parsed and sent a complete 200 OK set of HTTP headers back to the client. No, this is not an Apache bug. Running PHP 4.2.2 as a CGI via an Action directive under Apache 1.3.23 (RedHat patched). From httpd.conf: ## PHP run as a CGI without everyone needing ExecCGI privs AddType application/x-httpd-php .php .php4 .php3 .phtml AddHandler php-script .php .php4 .php3 .phtml Action php-script /lcgi/php ------------------------------------------------------------------------ [2002-10-21 20:40:02] [EMAIL PROTECTED] By default, the PHP executable runs in CGI mode and produces an HTTP header "Content-type: text/html" Since PHP runs in CGI mode, it should follow the CGI/1.1 specification, which has not changed in so long that it might even pre-date PHP! I refer you to: http://hoohoo.ncsa.uiuc.edu/cgi/out.html If PHP is going to leave something like the following in my Apache error log: PHP Fatal error: Unable to open /pub/a/b/acb.com/index3.html in Unknown on line 0 when it is unable to find a target file, then I would expect it to either return an error page 404 Not Found, or exit non-zero, at which point Apache will return 500 Server Error. Under NO circumstance should a PHP Fatal error return a 200 OK to the client, which is implicitly done by Apache as per the CGI/1.1 spec when Apache receives pieces of a valid HTTP header without "Status: xxx" specified. Incorrect PHP behavior confirmed on PHP 4.2.2 on Linux 2.4.18, RedHat 7.2. PHP custom compiled with: './configure' '--prefix=/usr/local/php' '--enable-memory-limit' '--enable-force-cgi-redirect' '--enable-safe-mode' '--disable-rpath' '--with-mysql' '--with-db3' -Glenn ------------------------------------------------------------------------ [2002-09-23 14:59:17] [EMAIL PROTECTED] Re-opening bug report. ------------------------------------------------------------------------ [2002-09-23 13:46:12] [EMAIL PROTECTED] Dear Kalowsky, I've just reproduced it on php4-200209200000 on Apache. It said php-4.3.0 in phpinfo(), and it is more recent than your post. You should understand that it is Apache-related bug, so IIS testing does not apply here, and it is stated in original bug report. Probably you also used php module in your testing on FreeBSD, while original bug report says that PHP was installed as CGI. The trouble looks to me as follows: if php CGI meets nonexistent php file, it does not output anything, while it should output error page, and I would really appreciate if I'd be able to tune that page via php.ini or whatever. Unfortunately, I can't reopen this bug, so someone please reopen it. Thank you. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14409 -- Edit this bug report at http://bugs.php.net/?id=14409&edit=1
