Here's the patch:
  http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/php4/patches/patch-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

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?