Description:
------------
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:
   http://cgi-spec.golux.com/
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:
  http://www.php.net/features.commandline
(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.

Cheers,
Luke Mewburn.

Here's the patch:
 
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/php4/patches/p
atch-aa?rev=1.10&content-type=text/plain

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.

-Shane

Problem still exists in PHP-5.0.2 on SunOS

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:
* php.so 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.

The provided patch was not correct, according to Frank. Assigning to him
for now.

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?

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.

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.

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.

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.

This is getting retarded...Why is this STILL not fixed? 
Seriously...WTF?

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.

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).

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).

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

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".

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".
Then
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
works!

Note that there is now an informative-doc RFC for CGI 1.1 
http://www.ietf.org/rfc/rfc3875
and it says that _name is a MUST, but _filename is optional, in fact it
is not mentioned there (it is an Apache extension).

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:
http://pastebin.ca/1296199
I wrote and tested this wrapper for thttpd only.

-- 
  Serge