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

ID: 9852 Updated by: timoid@getonit.net.au Reported By: ron.baldwin@sourceprose.com Status: Open Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: I can make this error happen every time within virtual hosts... the default www page however, works perfectly. weird Previous Comments: ------------------------------------------------------------------------ [2002-06-02 20:16:00] scott@datalink.net.au Another observation - when my script runs correctly, it takes a second to execute. When the CGI error occurs, it returns very quickly. This indicates that it fails on or around the first db statement (I'm guessing around the mssql_connect() statement). It's also consistent with the other users' comments on redirecting seeming to fail with a CGI error, but the location bar of the browser changing. The redirect *is* working, but it's the second page that fails (probably around reconnecting to the database). ------------------------------------------------------------------------ [2002-06-02 17:09:50] theo.schoeberl@tssystems.de We have the same problem (see Bug #11788). Loading the page outside the local network (over the internet) works in 99%. Within the local network the problem occurs on nearly ever 2nd load. After a relaod request of the individual frame (context menu - right mouse buttom) it works fine! It seems that the problem depends from the line speed and not the machines speed. ------------------------------------------------------------------------ [2002-05-28 09:16:11] scott@datalink.net.au Some further info on the problem: I applied the slowdown script after each query (in the simpleQuery method of PEAR's mssql driver) but I still got the occasional CGI Error (and it was awfully slow, too). I then applied the slowdown script at the start of each script, but still to no avail. What I did notice was that it did help the problem, but not eliminate it. My problem was still there when I refreshed my entire frameset (which caused 6 scripts to run mssql db commands simultaneously). Often 2 or 3 of these scripts failed with CGI errors. ------------------------------------------------------------------------ [2002-05-28 08:30:12] scott@datalink.net.au I tried the ISAPI module, but that died in *lots* of other ways - I get the impression I should stay with CGI :( I've since tried playing with the mssql parameters in php.ini (thought persistent connections may be the problem) with no success. I think I may try that slowdown script, but against all queries - it didn't work for me before the redirect - I don't always have a redirect :( Any other suggestions welcome... ------------------------------------------------------------------------ [2002-05-28 06:10:52] scott@datalink.net.au I have the same problem, but I have some more interesting facts to add... I can reproduce it with mssql or odbc drivers, and intererstingly I can get it breaking without using a header redirect. I have an application that uses a frameset, and it appears that sometimes (2 out of 3 times) it will give me the CGI error in multiple frames, even though I've switched from header redirects to javascript redirects. The URL changes at the browser, and it's the target page that fails to load - not the page with the redirect code. I have also had it failing on another page that used the IIS custom error page functionality (i.e. replacing a 404 error with a nice custom page)...again, a "fast redirect" issue, just like the original bug reporter. I do believe it is a timing problem - for me it only fails on a fast dual-processor production server, but works fine on my slower single-processor development server. It also works fine if I shift the production server to a MySQL database. Note that I tried using the slowdown function above, but it didn't work for me - perhaps multiple simultaneous page loads from the frameset also breaks it? By the way, mine fails on version 4.2.1 (released May 2002), so obviously this little bug hasn't been caught for over a year. I read above that the ISAPI version doesn't seem to do it, so I'll look at implementing ISAPI for this job. However, that could mean that it's to do with the persistant database connection, as the ISAPI module remains loaded between page views. ------------------------------------------------------------------------ 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