ID:               28227
 Updated by:       [EMAIL PROTECTED]
 Reported By:      lukem at NetBSD dot org
 Status:           Assigned
 Bug Type:         CGI related
 Operating System: *
 PHP Version:      5CVS, 4CVS (2005-02-04)
 Assigned To:      fmk
 New Comment:

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


Previous Comments:
------------------------------------------------------------------------

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

------------------------------------------------------------------------

[2006-05-26 20:52:04] wink15 at hotmail dot com

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

------------------------------------------------------------------------

[2006-03-15 17:00:13] 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-03-04 15:42:59] 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.

------------------------------------------------------------------------

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

Reply via email to