ID: 28227 Comment by: al dot rivero at gmail dot com Reported By: lukem at NetBSD dot org Status: No Feedback Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment:
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). Previous Comments: ------------------------------------------------------------------------ [2007-07-03 01:00:01] 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-06-25 23:44:14] [EMAIL PROTECTED] 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 ------------------------------------------------------------------------ [2006-08-10 19:05:01] [EMAIL PROTECTED] 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). ------------------------------------------------------------------------ [2006-08-10 00:04:42] 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-09 18:30:05] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28227 -- Edit this bug report at http://bugs.php.net/?id=28227&edit=1
