To reproduce, enter a bogus filename in a browser.  For example,
http://www.teamITS.com/blahblah.php.  The server returns an Internal
Server Error rather than a 404 (page not found) error.  I reported this
to Apache and their response was:

"This is the way the appropriate directives work on purpose (although
you didn't say just how you had PHP configured to run), since it is
possible to create a virtual URL space.  The PHP module is the one
deciding how to handle requests for nonexisting files."

Their issue number was mod_cgi/8683 (as PHP is installed as a CGI module
on this server).  Sounds to me like they are saying PHP should be
returning an error to Apache.  If you want more info on the PHP setup on
our server, browse to:
http://www.teamits.com/phpinfo.php

Note that a PHP/IIS4 combination does return a 404 error.

To clarify the comment about IIS, PHP is installed as a CGI (php.exe) on
that server.

Please show us the lines in the apache log file of such an request.

Derick

Note PHP version change from 4.0.6 to 4.1.2 (same issue).

error_log entry:
[Tue Jun 18 11:13:31 2002] [error] [client 64.81.224.87] Premature end
of script headers: /u/httpd/cgi-bin/php4.cgi

Interesting note, however...the problem does occur now on IIS/PHP 4.1.2
- "CGI Error
The specified CGI application misbehaved by not returning a complete set
of HTTP headers. The headers it did return are:"
(there the error ends).

Same problem is occuring on Debian 3.0 Linux - worked fine (as a cgi) on
the older version of Apache present in 2.2r7 - Only started 500 erroring
instead of 404'ing when Apache 1.3.26 was installed as part of the
upgrade.

Forgot to tell you that it's an i386 Architecture :)

Unable to reproduce this on IIS with PHP 4.3.0-DEV, and on FreeBSD 4.6. 
Please try a newer version.  Marking as closed, because I guess this was
a valid bug, and has been fixed.  

Duplicated again with PHP 4.2.2 on Apache 1.3.23 under Windows XP.  I
don't have access to 3.0.

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.

Re-opening bug report.

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

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

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.

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

I applyied the 4.3.0 "patch" basicaly replacing the old cgi_main.c with
the downloaded one, compiled and installed.
But it seems that the problem still exists. When ever calling to an
unexisting file it still gives a 500 error.
I have apache 1.3.27 and php 4.3.1
I configured php as follow :
./configure --enable-force-cgi-redirect --enable-safe-mode
--with-openssl --with-zlib --with-gdbm --with-mysql
--enable-memory-limit --with-gd --with-jpeg-dir=/usr/lib
--with-zlib-dir=/usr/lib --with-png-dir=/usr/lib

Re-opening bug report.  I do not see the Internal Server error, however
the nonexistent PHP page (http://www.teamITS.com/blah.php) now returns:

"Fatal error: Unknown(): Unable to open in Unknown on line 0"

When installed as an Apache module (Windows, Apache 1.3.27) it returns
the correct 404 error.

yes this what I get on linux too.
moreover you don't need to try accessing the file through the web you
can execute something like that:
php blah.php and this is what I got from php:
Content-type: text/html
X-Powered-By: PHP/4.3.1

PHP Fatal error:  Unknown(): Unable to open blex.php in Unknown on line
0

php -v :
PHP 4.3.1 (cgi), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

anything new with this bug ?

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Tested with 4.3.2 on windows, 404's are returned fine.  Please try the
latest RC of 4.3.2.

Sorry, I have limited methods of testing Unix releases.  PHP Version
4.3.2-RC3-dev under Apache now returns "No input file specified." for a
non-existent file, instead of a 404 error.  Slightly better than before
but a 404 still seems like the best/target solution, so the web server
can log errors properly.

When using RC4, I get this:
Status: 404 Content-type: text/html X-Powered-By: PHP/4.3.3-dev No input
file specified.

(all text shown on the page, ie. the headers too!)

And when I try this on command line: php-cgi non-existing.php
it just sits there doing nothing.

Shane, this is pretty critical, especially the added headers on the page
for existing file:

tent-type: text/html X-Powered-By: PHP/4.3.3-dev

that was the latest CVS checkout of PHP_4_3 branch of course,
but it has the same sapi/cgi stuff in it as RC4 has.

This happens when your php.ini contains something that
causes a non-fatal error message. I had browscap.ini set
to such permissions that it could not be loaded by the CGI binary.

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.