I don’t get it. I’ve never seen a problem like this, and I guess this is why I know I’m still green. I set up my config file, and then I got this error before the installer ran:
The specified CGI application misbehaved by not returning a complete set of HTTP headers.
Can anyone tell me what this might be? Check me online at
It looks to be an issue with the (IIS) server your site is on, which is obviously running PHP in CGI mode. I would contact your host with the error.
I checked just now with the server team – they said nothing seems to be wrong. I’ll get them to check the IIS.
Is there anything else I can try?
(Interesting though… I installed a lot of these blogs – never had a problem!)
Ok… We reset IIS, and still nothing. What Next? Sigh…
This is not an issue of having to reset the server:
For a quick check of PHP on the server, create a PHP document (say test.php) with just the following in it:
<?php phpinfo(); ?>
Upload that doc to your server and access it through your web browser. If it generates the same error…
Seen this on a number of different hosts and the only thing I’ve been able to suggest is to consider changing over to a linux based host.
This happens on NT IIS servers running FastCGI. The phpinfo runs fine. 2.3.2 returns the CGI error, and 2.3.1 will display the initial installation screen (not properly formatted) asking for the blog/email info but after enter that information, it will return “HTTP Error 404 – File or directory not found. Internet Information Services (IIS)”
Here’s an example phpinfo experienced recently:
PHP Version 5.1.4 System Windows NT D100 5.2 build 3790 Build Date May 4 2006 10:30:29 Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--with-gd=shared" Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20041225 PHP Extension 20050922 Zend Extension 220051025 Debug Build no Thread Safety enabled Zend Memory Manager enabled IPv6 Support enabled Registered PHP Streams php, file, http, ftp, compress.zlib Registered Stream Socket Transports tcp, udp Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.* Zend logo This program makes use of the Zend Scripting Language Engine: Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend Technologies
I’m experiencing ( possibly related? ) problems with a similar setup ( http://wordpress.org/support/topic/150672 ).
Do you have available the result of phpinfo(INFO_MODULES); for a WIN/IIS6 system WITHOUT fastCGI that’s known to work?
What I mean is, the previous post seemed to imply that it is FastCGI that’s causing the headache — is that a gut feeling, or do we know for sure?
I had a similar problem with my installation, but I resolved it by following the tip from CGI Error with pages.
@dhbarr — didn’t mean to imply it was FastCGI causing the problem but the 4 or 5 times I’ve checked the phpinfo on problem sites, FastCGI was in use.
I’m going to give it a try today. I’ll leave EVERYTHING else the same, except modify WordPress to not use FastCGI at all, but rather the default php handling method.
I have a hunch that there’s a version issue somewhere in the php-mysql-fastcgi triangle, based on this post:
Today I’ll try disabling FastCGI first, down-revving MySQL next, down-revving PHP after that, and finally walking backward through WordPress releases as a last resort. Hopefully ONE of these options will clear up the mystery.
Change that “4 or 5 times I’ve checked the phpinfo on problem sites” to “5 or 6 times”. 🙂
I changed IIS6 for that particular website to use php5isapi.dll instead of fcgiext.dll, and presto!
Some combinations of IIS6, PHP5, and FastCGI simply do not work — apparently this is FastCGI’s fault, which isn’t entirely surprising since it’s only a tech preview.
This fix is to use php5isapi.dll instead.
Thanks for that information dhbarr!!
So guess this is something a host would typically have to change for a user?
Dunno if this helps this particular user, but it helped me personally…
I use Easy-CGI for my host provider and was running into this same error when I went to upgrade from 2.3.1 to 2.3.2. Easy-CGI allows you to use either PHP v4.4.4 or 5.2.4. Through their configuration menus, I discovered I was using 4.4.4 – once I changed it to 5.2.4, the error message went away. So something must be different between how Easy-CGI has 4.4.4 vs. 5.2.4 configured.
Here’s an explanation for dhbarr about how he solved the problem (see above) Thanks David.
Under %systemroot%/inetserv/fcgiext.ini I snipped out the reference to this particular subsite. I then added the PHP ISAPI Web Services Extension to this particular subsite, and set php5isapi.dll as the .php handler instead of fcgiext.dll for this subsite only. See steps 3.1 and 3.2 from this link if you’re not typically a Windows guy : http://www.peterguy.com/php/install_IIS6.html
I fretted over this for about 2 days. I’m a “wannabe” tech guy, but can’t quite follow all the technical jargon. Form what I understood, it’s a compatibility issue anyhow and that my particulary configuration didn’t work.
I’d installed WordPress many times on many servers and never encountered this problem.
What I did (and it worked) was simply install WordPress 2.3.1. I had to hunt around a bit to find that version, but Presto! it works.
Trying WordPress 2.3.1 has not worked, at least on the several hosts I’ve had a occasion to try…
While 2.3.1 may not display the CGI error, it will display the installation screen in an unproperly formatted mode, allow you to enter the Blog title and Your email fields, but when you click on the Install WordPress button, it will display an error page with the message “The page could not be found…(HTTP Error 404 – File or directory not found. Internet Information Services (IIS))”
- The topic ‘CGI Script Error?’ is closed to new replies.