Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
| From: | davidr at gronks dot com | Date: | Fri, 21 Jun 2002 07:10:27 +0000 |
| Subject: | Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved" | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-11642@lists.php.net to get a copy of this message | ||
ID: 9852
Updated by: davidr@gronks.com
Reported By: ron.baldwin@sourceprose.com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
I have found that by removing anonymous IUSR permissions on the web
site and then logging into the web site using an administrators
creditonals that the error will not occur.
The error will also not occur if the web sites anonymous user is set to
run as a user that has local Administrator privledges.
Previous Comments:
------------------------------------------------------------------------
[2002-06-18 23:07:36] scott@datalink.net.au
Kai, when you mentioned 'under 2MBit' were you meaning 2 Mbit/s or 2
MB/s? IIS prompts for KB/s, so I assumed for your solution you
limited it to 2,048 KB/s?
For our machine, we can limit it to < 350 KB/s and it appears to solve
the problem, but I haven't stress-tested the server yet. This is good
news for us - we can get paid for our project. But this bug will
likely re-appear as server equipment gets faster.
In other news we've pulled down the PHP source and did some further
debugging... we found:
1. The error occurs on the first 'dbexec' command run in the mssql
driver. For example, in PHP it will not happen on a mssql_connect(),
but on the *next* mssql command issued in that script (say a
mssql_select_db() or a mssql_query()). Our test script will run fine
if we connect to mssql but don't use it in any way after that.
2. We laced the PHP source with some fwrite()'s to stout to watch the
flow of the code - when PHP failed, we didn't get any of these, not
even the ones placed *before* the mssql_connect() function definition.
This may indicate that PHP is not crashing, but IIS may not even be
loading it in the first place! (strangely seems to conflict with point
1).
3. We can reproduce it quite freely under varying bandwidth and on
fast and slow computers (happens more frequently on faster machines).
Limiting the bandwidth on IIS does seem to fix the problem (under
single user situations)
4. We have ported the same script to ASP without reproducing this bug.
ASP seems to run fine.
5. We can reproduce it under ISAPI and CGI using our test script
(below) - the ISAPI script fails less often than the CGI version, but
it still fails.
6. It breaks under ODBC, too.
IMHO, I believe that it is critical to the ongoing success of PHP to
have it working with Windows 2000 and/or MSSQL. Simply blaming it on
Microsoft and closing the bug is unacceptable, especially as this bug
seems to occur more often with faster servers. This bug will hurt more
and more people into the near future, and damage the reputation of this
fine product (PHP, that is).
Our investigations do suggest that the bug is likely in IIS, but
nevertheless it will hurt PHP more than Microsoft as the bug affects
more people.
With regards to your suggestion on PERL/ASP exhibiting the same
problem, I haven't been able to reproduce it with them (if you supply
your ASP test script, I'll test it with my config here).
I'd appreciate you marking this bug 'open' rather than 'bogus', as it
needs to be solved regardless of who is to blame.
Best regards,
Scott
NB: My company is working on the problem to try to solve it - I will
post our findings or workarounds to this bug page. If anyone knows of
other related bugs I would appreciate it if you can post them here.
NB2: Has anyone had success with a Cygwin-compliled PHP?
---------- Test Harness Follows --------------
index.php:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>MSSQL Test</title>
<script>
var count = 0;
</script>
</head>
<!-- frames -->
<frameset cols="20%,20%,20%,20%,20%">
<frame name="frame1" src="mssql_test.php?j=<?php echo ++$j; ?>">
<frame name="frame2" src="mssql_test.php?j=<?php echo ++$j; ?>">
<frame name="frame3" src="mssql_test.php?j=<?php echo ++$j; ?>">
<frame name="frame4" src="mssql_test.php?j=<?php echo ++$j; ?>">
<frame name="frame5" src="mssql_test.php?j=<?php echo ++$j; ?>">
</frameset>
</html>
mssql_test.php:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>MSSQL Test</title>
<script>
top.count++;
</script>
</head>
<body>
<?php
print "<h1>$j</h1>\n";
$dbConn = mssql_connect("localhost", "sa", "<password>");
mssql_select_db("cogs", $dbConn);
$result = mssql_query("SELECT * FROM site", $dbConn);
while ($array = mssql_fetch_row($result)) {
print "<pre>";
print_r($array);
print "</pre>";
}
?>
<script>
if (top.count == 5) {
top.location = 'frameset.php?j=<?php echo $j ?>';
}
</script>
</body>
</html>
---------- End test harness ----------
------------------------------------------------------------------------
[2002-06-08 15:09:38] k.schroeder@php.net
IMHO this is not a bug in PHP. Using ASP or Perl with ISS, I have the
same problem. After reducing bandwidth to 2MBit I can't reproduce this
bug. Please try this and feel free to reopen.
------------------------------------------------------------------------
[2002-06-06 03:26:36] taomyn@hotmail.com
I also meant to add that the site counter and other parts use MySQL as
it's db - in case that helps.
------------------------------------------------------------------------
[2002-06-06 03:24:05] taomyn@hotmail.com
I am getting the same issues with 4.2.1 under Win2k and IIS (small
site, not much access), but it's happening with both the EXE and ISAPI
modules, and happens immediately after any access to Activer Server
Pages!
------------------------------------------------------------------------
[2002-06-04 16:04:59] theo.schoeberl@tssystems.de
We have tested usleepWindows(200000) and it works for us.
It also works within frames on a virtual site!
------------------------------------------------------------------------
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/9852
--
Edit this bug report at http://bugs.php.net/?id=9852&edit=1