Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"

From: Date: Wed, 19 Jun 2002 03:07:38 +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-11326@lists.php.net to get a copy of this message
ID: 9852 Updated by: scott@datalink.net.au Reported By: ron.baldwin@sourceprose.com Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: 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 ---------- Previous Comments: ------------------------------------------------------------------------ [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! ------------------------------------------------------------------------ [2002-06-04 15:49:23] theo.schoeberl@tssystems.de Sorry, we have the same problem on a site with no frames and with a real (and its own) ip address! I think its a problem with des MSSQL-Library. There are a lot of articles in the microsoft knowledgebase! ------------------------------------------------------------------------ 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

« previous php.bugs (#11326) next »