#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"

ID: 9852 Comment by: ottawasixtyseven@hotmail.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 agree with Scott. PHP should be made to work with enterprise products. Even if the problem is not PHP's fault we still need to know exactly what causes it. It's very interesting that when Scott sets Performance Options to forground it solves his CGI error completely. It's even more interesting that MDAC 2.7 doesn't help him. This is our latest experience with a client who just installed our PHP application. Client System Configuration: 1.4 GIG processor, M$ 2000 Server, IIS, PHP, M$ SQL Server. Client installed our application. CGI errors out the ying-yang (this error happens more frequently on a machine with a fast processor). Told Client to install MDAC 2.7 RTM. Unfortunately (or fortunately depending on how you look at it), the client also decided to install this patch at the same time: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-009.asp So, we've found some new, interesting information from Micro$oft: "Incorrect VBScript Handling in IE can Allow Web Pages to Read Local Files" Micro$oft also talks about third party scripting languages: "... Microsoft has become aware of a handful of third-party applications that depend on unforeseen behavior in VBScript that this patch disables." So good news and bad news. Bad news: We don't know if MDAC 2.7 fixed our clients CGI erros or if the MS02-009 fixed it. Good news: we've found yet another possible solution (MS02-009) If anyone has a really fast machine out there maybe they can test this MS02-009 fix. Please post your findings here. Ottawa Previous Comments: ------------------------------------------------------------------------ [2002-08-28 02:28:14] scott@datalink.net.au Hi all, As a followup a few weeks later, I can confirm that setting the server performance to optimise for 'Forground Applications' solves the CGI Error problem completely. My guess is that PHP is launched as a CGI in user space (owned by IUSR_*), so tuning the server this way gives it more processing time. I guess the MSSQL module likes it this way. I have also had emails from others asking for assistance on this, and have had positive feedback from them that it fixed their problem, too. Scott. ------------------------------------------------------------------------ [2002-08-05 02:14:38] scott@datalink.net.au Further to my other posts, some more constructive data to add to the debug efforts: 1. I now can replicate this on my XP notebook, by setting performance options to 'background services' rather than the default 'foreground applications'. It seems that MDAC 2.7 has no effect on the problem occurring as it's bundled with WinXP. 2. It seems I can prevent the problem from occurring on the production box by setting it to 'foreground applications' rather than 'background services'. This is the most successful workaround to date (for me). It also confirms that the problem is related to processor speed or timing. Scott ------------------------------------------------------------------------ [2002-08-05 00:39:36] scott@datalink.net.au I applied the MDAC 2.7 Refresh patch from Microsoft to our troublesome server, and unfortunately this did not solve the problem. On our new notebook (1.6Ghz P4, WinXP) the problem does not occur at all. XP uses MDAC 2.7, too... Could be that the notebook is slower (the production machine is dual processor P3 1Ghz). Still searching for an answer... By the way, has anyone tried using the ADO COM object? Scott ------------------------------------------------------------------------ [2002-08-04 22:48:49] scott@datalink.net.au Here's a reason to open this bug: If PHP worked properly with enterprise products we would consider using it for enterprise solutions. How can you state that there is nothing solid to go on, considering the opening bugnote begins with: "Under the category of 'You Can Never Have Too Much Information On A Bug'", and this bug has over 600 lines of descriptive information, including step-by-step procedures and scripts to reproduce it! Regardless of who is to blame (IIS, MSSQL, PHP, Solar Flares), the bug exists anyway, and it is in the interest of PHP to track it. By closing this bug because somebody claimed that a MDAC upgrade *may* solve the problem is wrong. If all bugs were handled using hearsay I would not feel comfortable about the quality of PHP in general. How about having someone who can replicate this bug become responsible for it, and only when they are happy should the bug be closed. I am happy to become this person, to help improve the quality of the PHP codebase and the support team. In the meantime, please re-open this bug. ------------------------------------------------------------------------ [2002-07-15 11:48:06] rasmus@php.net There is really nothing solid to go on here. Everything points to an IIS issue, and as mentioned upgrading MDAC seems to fix it, so unless there is some real evidence that this is something we can fix at the PHP level, I see no reason for this to be an open bug in the PHP bug database. ------------------------------------------------------------------------ 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