php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14409 request for nonexistent file does not return 404 error
Submitted: 2001-12-10 14:38 UTC Modified: 2003-05-26 18:22 UTC
Votes:9
Avg. Score:4.7 ± 0.7
Reproduced:8 of 8 (100.0%)
Same Version:4 (50.0%)
Same OS:3 (37.5%)
From: support at teamITS dot com Assigned: shane (profile)
Status: Closed Package: CGI/CLI related
PHP Version: 4.3.2-RC3-dev OS: IRIX64 www102 6.5 07091542 IP27
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: support at teamITS dot com
New email:
PHP Version: OS:

 

 [2001-12-10 14:38 UTC] support at teamITS dot com
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-19 11:34 UTC] support at teamITS dot com
To clarify the comment about IIS, PHP is installed as a CGI (php.exe) on that server.
 [2002-06-18 04:04 UTC] derick@php.net
Please show us the lines in the apache log file of such an request.

Derick
 [2002-06-18 11:25 UTC] support at teamITS dot com
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).
 [2002-07-31 09:00 UTC] phil at lchost dot nospam dot co dot uk
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.
 [2002-07-31 09:01 UTC] phil at lchost dot nospam dot co dot uk
Forgot to tell you that it's an i386 Architecture :)
 [2002-08-10 09:59 UTC] kalowsky@php.net
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.  
 [2002-08-13 00:49 UTC] support at teamITS dot com
Duplicated again with PHP 4.2.2 on Apache 1.3.23 under Windows XP.  I don't have access to 3.0.
 [2002-09-23 13:46 UTC] stas_k_php at tiger dot unisquad dot com
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.
 [2002-09-23 14:59 UTC] support at teamITS dot com
Re-opening bug report.
 [2002-10-21 20:40 UTC] gs-bugs-php at gluelogic dot com
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-10-22 02:05 UTC] gs-bugs-php at gluelogic dot com
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
 [2003-01-21 15:31 UTC] brian at zyx dot net
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.
 [2003-01-25 16:26 UTC] shane@php.net
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


 [2003-05-07 17:45 UTC] romio at netvision dot net dot il
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
 [2003-05-08 00:32 UTC] support at teamITS dot com
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.
 [2003-05-08 04:48 UTC] romio at netvision dot net dot il
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
 [2003-05-18 03:26 UTC] romio at netvision dot net dot il
anything new with this bug ?
 [2003-05-18 22:01 UTC] shane@php.net
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.
 [2003-05-24 01:30 UTC] support at teamITS dot com
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.
 [2003-05-24 02:23 UTC] sniper@php.net
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


 [2003-05-24 02:25 UTC] sniper@php.net
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.

 [2003-05-25 21:10 UTC] sniper@php.net
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.

 [2003-05-26 18:22 UTC] sniper@php.net
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.


 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Fri Dec 04 18:01:23 2020 UTC