ID: 9852
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
We have chanced our PHP-Script from using ODBC to native MSSQL (using
the MSSQL library). The same error (incl. 502 Bad Gateway).
The next try was to change the server name to its IP address within the
connect statement - and it works!!!!!
No error since the change, running now over 14 days!
May be there is a problem (known under Windows systems) resolving the
server name?
Hope this helps a lot of PHP developers running Windows systems!
Theo
Previous Comments:
------------------------------------------------------------------------
[2003-01-07 17:29:12] [EMAIL PROTECTED]
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?
------------------------------------------------------------------------
[2002-12-28 19:08:25] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
------------------------------------------------------------------------
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
