|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28227 PHP CGI depends upon non-standard SCRIPT_FILENAME
Submitted: 2004-04-30 02:11 UTC Modified: 2007-07-03 01:00 UTC
Avg. Score:4.8 ± 0.4
Reproduced:44 of 46 (95.7%)
Same Version:11 (25.0%)
Same OS:11 (25.0%)
From: lukem at NetBSD dot org Assigned: fmk (profile)
Status: No Feedback Package: CGI/CLI related
PHP Version: 5CVS, 4CVS (2005-02-04) OS: *
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2004-04-30 02:11 UTC] lukem at NetBSD dot org
I upgraded PHP from 4.2.3 to 4.3.6 and I started getting the error "No input file specified." from the php-as-cgi whilst running under a (fairly minimal and small) web server called bozohttpd.

Further investigation reveals that sapi/cgi/cgi_main.c::init_request_info() is using the existance of SCRIPT_FILENAME to determine if php is running as a CGI.

However, the "defacto standard" for CGI/1.1:
makes no mention of SCRIPT_FILENAME, only SCRIPT_NAME.
Thus, when a web server that is used to run php as a CGI doesn't support SCRIPT_FILENAME (which is reasonable - see the specs above), php refuses to function and fails with the error above.

Some research into other web servers indicates that none of them support SCRIPT_FILENAME.  These servers include:
   thttpd, mini_httpd, w3c-httpd, OmniHTTPd - (PHP PR 25833), Xitami (PHP PR 25305)

This issue is also alluded to in the "command line" documentation on your web site:
(search for "no input file").

In summary, PHP 4.3.6 should not be relying solely upon SCRIPT_FILENAME to determine if it's running as a CGI.
I have a patch to fix this issue - rev 1.10 of NetBSD's pkgsrc/www/php4/patches/patch-aa - which I can provide if necessary.

Luke Mewburn.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-03 19:47 UTC] shane at caraveo dot com
The current code does not rely on script_filename, script_filename is only used as a shortcut if it is available.  Otherwise, the init function tries to determine the real script path, IF the fix_pathinfo ini setting is on.  The current code was only tested under apache and iis.

That said, the patch looks ok, and very likely improves the situation, but needs some good testing on apache/mod_php, apache/cgi, iis/isapi and iis/cgi, with various changes of configuration in php.ini (discard path, fix pathinfo, etc.).  Unfortunately I have zero time.

 [2004-12-13 20:33 UTC] jbardin at hsc dot usf dot edu
Problem still exists in PHP-5.0.2 on SunOS
 [2004-12-17 03:02 UTC] lukem at NetBSD dot org
This bug is still present in 4.3.10 as well.

Note that NetBSD's pkgsrc system has been using the patch I provided for a few months now, and we haven't received any reports of problems with PHP with that patch when running as a:
* module under Apache
* php CGI under Apache
* php CGI under web servers that don't support the non-standard SCRIPT_FILENAME

Please consider applying this patch, because without it PHP is useless as a CGI except under Apache & IIS.
 [2005-02-11 03:04 UTC]
The provided patch was not correct, according to Frank. Assigning to him for now.

 [2005-05-30 18:33 UTC] masta at yazzy dot org
I ran into this exact same issue with php4-cgi (ver 4.3.11) on FreeBSD due to the SCRIPT_FILENAME problem. I found two ways to avoid the non-standard CGI var is to hack the http server used (mini_httpd) or use LukeM's modifications to php4. Considering that CGI is a standards based domain, modification of the webserver to support non-standard CGI variables is not proper, thus the modification to PHP itself is the solution. I found that the the LukeM modification still allows for proper execution in apache.

Can somebody in the php team fix this please?
 [2005-07-26 05:24 UTC] joey at clean dot q7 dot com
it took me many hours of poking around to finally find this page to figure out why php isn't working under the httpd server provided under busybox.  php is clearly doing the wrong thing with respect to the cgi specification.  SCRIPT_FILENAME is not a standard header and can not be relied on to function.
 [2005-08-04 21:31 UTC] pgf at foxharp dot boston dot ma dot us
why hasn't this been fixed?  is there a real problem with fixing it?  i'm faced with a bug report against the busybox web server that i'd rather not fix, given that the problem is clearly a php problem.
 [2006-03-04 15:42 UTC] steve at suzail dot org
Still present in php-5.1.2-Win32

What's the big deal with fixing this problem?  It's such a major problem but needs so little to fix it.
 [2006-03-15 17:00 UTC] mike dot scarborough at yahoo dot com
I tried using Luke's changes within the php-5.1.2 source under netBSD, so that I could use the same bozohttpd server. 

Those changes didn't seem to help the problem under 5.1.2. I'd like to look into it further, but it would be very helpful if this could get fixed. Lots of times apache and iis are not options for a project.
 [2006-05-26 20:52 UTC] wink15 at hotmail dot com
This is getting retarded...Why is this STILL not fixed? 
 [2006-08-09 18:30 UTC]
because the patch is not correct and this is an incredibly fragile mechanism due to the wide variety of web servers out there.  And despite what the bug report says, PHP does not rely on SCRIPT_FILENAME being present, it simply uses it if it is there.  As far as I can tell using ./configure --enable-discard-path should take care of this problem.
 [2006-08-10 00:04 UTC] lukem at NetBSD dot org
If I recall correctly, PHP4 as a CGI _did_ rely upon SCRIPT_FILENAME being set by the web server, at least in the default build of PHP4.

My original workaround was to modify the non-Apache web server I was using to set SCRIPT_FILENAME before invoking php-as-cgi.

IMHO, it not an acceptable long-term solution to modify the _web server_ because the _CGI application_ (php) relies upon a non-standard CGI variable.  Which is why I developed the patch, which worked at the time for the release of PHP I was using (4.3.6).

Based on the replies I've seen to my bug report & patch, other people are also seeing this problem, even in newer releases of PHP.   Not everyone uses PHP as an Apache module, and not everyone uses Apache as a web server.

People that want to use php as a CGI on other minimal web servers (e.g, embedded systems) may run into this problem, spend time trying to fix it, get pushback from the PHP developer community about this not being a problem (c.f. the way various bug reports documenting a similar problem with the "no input file found" being closed as "configuration problem", when I show that it's PHP-as-CGI barfing because SCRIPT_FILENAME isn't set), and in the end punt and use another solution.

I strongly suggest that the PHP developers set up a test environment where PHP runs as a CGI from one of the many minimal (Open Source) web servers available that don't implement SCRIPT_FILENAME to attempt to reproduce this issue that numerous people have observerd (based on followups to this ticket, and other tickets that I've read).
 [2006-08-10 19:05 UTC]
The patch broke CGI on other web servers (IIS on Win32). That was the reason it was reverted. So far I have not been able to come up with a way to apply your patch so it will work in all cases (not breaking existing installed systems).
 [2007-07-03 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2007-12-27 01:16 UTC] al dot rivero at gmail dot com
with PHP/5.2.3-1ubuntu6.2
php-cgi ejemplo.php
works, but
REQUEST_METHOD=GET php-cgi ejemplo.php
doesn't work, it produces the bug, "No input file specified".
REQUEST_METHOD=GET SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php
works, and more suprisingly
SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php
works, and
SCRIPT_FILENAME=ejemplo.php php-cgi

Note that there is now an informative-doc RFC for CGI 1.1
and it says that _name is a MUST, but _filename is optional, in fact it is not mentioned there (it is an Apache extension).
 [2008-12-30 05:47 UTC] serge at localhost dot localdomain
The bug is still somewhere there.
$ php-cgi --version
PHP 5.2.6 (cgi-fcgi) (built: May  8 2008 08:52:59)

Until it gets fixed in either php-cgi or webservers-side here's a workaround-wrapper:
I wrote and tested this wrapper for thttpd only.

 [2014-09-12 11:57 UTC] xsrm0j4w8778b7t at jetable dot org
What if one uses, say php-fpm: how can the absolute path of the script.php be determined? 

I suppose fpm needs that information to be able to launch the script. 

I see no way of doing that in a fool-proof manner, based on the CGI 1.1 RFC. Even looking at the current directory is not garanteed to work. RFC says: "The current working directory for the script SHOULD be set to the directory containing the script."

Is this the reason why SCRIPT_FILENAME is used?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 05:01:29 2024 UTC