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

ID: 9852 Comment by: vincent@sunlight.tmfweb.nl Reported By: ron.baldwin@sourceprose.com Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: Just an idea: does it help to close the database connection right before calling the header('Location: URL') function? I understand that putting in a timer helps (most of the time), but I think that's a bit of an ugly solution. I mean: how long should you wait? The ideal number of microseconds to sleep depends on the server, the load on the server, and so on. As the problem occurs when there is a database connection, I wonder if it goes away if this connection is closed, before doing the real redirecting. Sadly enough I can't test this myself, because I don't have access to a server that's fast enough. Anyone? Previous Comments: ------------------------------------------------------------------------ [2002-12-28 19:08:25] theo.schoeberl@tssystems.de We have posted this problem first at 2001-06-28 (ID# 11788). This request was closed (Bogus) with the following comment: Once and for all: It's not the lack of interest, it's the lack of good developers with knowledge about it. Historically, OpenSource projects operating in cross-platform environments have a stronger unix developer community. It's a fact. I think, the best way for IIS-Users is, to develope there page under ASP! And for PHP you should say: running under all unix plattforms - but not under IIS! ------------------------------------------------------------------------ [2002-12-27 07:00:54] nicolas@colbert.ws Good Afternoon, I have seen many comments regarding PHP should be compliant with enterprise software. I would suggest that it is - UNIX and Apache are enterprise level solutions and PHP is a ROCK star on those platforms. Just because we are no forcing it to do things on an AXX Backward platform like MS W2k and XP is not a reason to complain. I have run into the issue, because I am having to rewrite our authentication scripts because the IIS CGI cannont handle a simple authentication redirect. Before you blame PHP, try looking at all the garbage hoops that IIS puts you through. Nicolas ------------------------------------------------------------------------ [2002-11-14 06:36:33] ulysses@mail.fitan.com.tw Just for your information: Don't blame PHP. ASP.net ALSO SHOWS LOTS OF "CGI ERROR". I solve this problem by slowing down connection -- do not put src='xxx.php/asp' in your frame tag. use onload() handler to load page into frames with javascript AFTER the frame page is loaded. ------------------------------------------------------------------------ [2002-10-29 14:00:20] ottawasixtyseven@hotmail.com I'm happy to hear that most people are able to solve their CGI errors by changing the Windows Performance Options. We have Scott to thank for this little trick! Rasmus, I think what people are upset about is that this bug was closed. It's obviously a Micro$haft problem (big surprise) but even so, it's quite frustrating to feel like y'all don't give a dern :-( This is obviously not the case but closing the bug makes people think that you're not interested in finding a solution. Even if the problem is not the fault of PHP. On an unrelated note I'm *extremely happy* to see that you've included the php_zip.dll extension in php-4.3.0pre2-Win32.zip. SWEEEEEEEEEEEET! Now all we need is a solid php4isapi.dll ;-) Ottawa ------------------------------------------------------------------------ [2002-10-28 19:35:21] rasmus@php.net We fix what we can fix given our resources and the environment we are working in. In many ways M$ does not provide us with a level playing-field and as such you will find that PHP is much much stronger on non-M$ platforms where we are not hampered by closed-source, vague and often quite buggy apis. But thank you for your amazingly constructive comments. ------------------------------------------------------------------------ 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