Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
| From: | scott at datalink dot net dot au | Date: | Mon, 03 Jun 2002 00:16:01 +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-9265@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: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
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).
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2002-04-22 17:50:12] sp@m-me.dk
It seems to be a timing problem (the PHP script outruns the IIS/MSSQL
or something). I came up with a simple solution to this by inserting a
short delay before every location header in my scripts.
I successfully made the workaround by using a function from a user
comment on the http://www.php.net/manual/en/function.usleep.php
page
The function was:
------------------------------
function usleepWindows($usec) {
$start = gettimeofday();
do {
$stop = gettimeofday();
$timePassed = 1000000 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while($timePassed < $usec);
}
------------------------------
Every header call should then look like this:
------------------------------
usleepWindows(200000);
header("Location: http://www.myserver.dk/mypage.php");
exit;
------------------------------
/watson
------------------------------------------------------------------------
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