php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #371 PHP causes failure of conventional CGI scripts?
Submitted: 1998-05-12 04:38 UTC Modified: 1998-05-15 05:54 UTC
From: sean at interactivate dot com Assigned:
Status: Closed Package: Performance problem
PHP Version: 3.0 Latest CVS OS: linux 2.0.33
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: sean at interactivate dot com
New email:
PHP Version: OS:

 

 [1998-05-12 04:38 UTC] sean at interactivate dot com
PHP makes old CGIs unusable? 
    clever method of PHP evangelism!

apache 1.2.7 and apache 1.3b{6,7} that have the latest php 
compiled in as an apache module cause "legacy" CGI scripts
(perl, sh) to fail about 1/8 times with a "premature end 
of script headers" error reported in the apache error_log.
nothing special is reported in the optional apache 
scripterror_log when that is turned on.

we do not use any php.ini file.

the san diego zoo (www.sandiegozoo.org) handles about 
2.25 million raw hits per month, several of the site's
most popular features rely on simple Perl cgi scripts 
(the kind of thing PHP was invented to outdo in a big way, 
and we were evaluating until this incompatibility with 
the Zoo's old Perl CGI's).

when the zoo's dedicated apache httpd is recompiled using 
the current CVS version of PHP, ALL of the zoo's 'legacy' 
CGI scripts fail intermittently with a "premature end of 
script headers" error. reloading the web page containing 
the troublesome legacy CGI script usually works the 2nd or 
third try. its not just the zoo's custom scripts but ANY 
CGI script, we tried Perl and sh, even the simplest 
'hello world' examples.

i've used CVS for about one year now, never mixed it with 
any 'mere CGI' applications in a site until now. working on 
this problem i've hand-built many possible combinations of 
apache and PHP, called in the Perl expert, the kernel expert,
everyone was baffled, especially since the PHP demos i ran 
worked flawlessly and measurably better on the same server 
where the conventional CGI's were failing :-). 

EVEN the simple example CGI's provided with the 
Apache distribution such as test-cgi and printenv.pl 
FAILED intermittently in every server/php build variation 
combination until i finally broke down, yanked out all the 
PHP web pages, and turned on a non-PHP version of apache, 
hand-built from the same 1.3b7-DEV apache sources that PHP 
was compiled into moments earlier.

here's the ./configure line i used for most apache 1.3.x 
builds with PHP:

./configure \
        --activate-module=src/modules/php3/libphp3.a \
        --logfiledir=/www/sandiegozoo.org/apps/siteconfig/logs \
        --runtimedir=/www/sandiegozoo.org/apps/siteconfig/run \
        --sysconfdir=/www/sandiegozoo.org/apps/siteconfig/etc \
        --enable-module=status 

thanks for looking into this buglet, i'd hate to see PHP3 
released and then legacy CGI scripts start failing all over 
at ISP's and intranets and there's a backlash against PHP? 

if you want a simple CGI script to reload about 20x and 
see the intermittent failure, you can use the test-cgi or 
printenv.pl included with apache, i'll paste one below as 
well.

hope there's a simple fix!
--sean

### printenv.cgi, run about 20x and it should fail 1-2x
### with "premature end of script headers" in error_log
#!/usr/bin/perl

print "Content-type: text/html\n\n";
while (($key, $val) = each %ENV) {
        print "$key = $val<BR>\n";
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1998-05-15 05:54 UTC] zeev
Fixed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 09:01:26 2024 UTC