Question

"CGI Error - The specified CGI application misbehaved by not returning a complete set of HTTP headers."

Perl test files ("hello world") run without error via IIS 6. When view.pl is run via the command line, in generates proper html.

Here is part of the configure.pl:

Operating system Windows (MSWin32) Perl version 5.8.8, build 817 (ActiveState) @INC library path ../lib D:\data\TWiki-4.0.1\lib c:/Perl/lib c:/Perl/site/lib .

This is the Perl library path, used to load TWiki modules, third-party modules used by some plugins, and Perl built-in modules. CGI bin directory . TWiki module in @INC path OK, TWiki.pm found (Version: Wed, 08 Feb 2006 build 8740) Required Perl modules Error 0.15 File::Copy 2.09 Net::SMTP 2.29 MIME::Base64 3.07 File::Spec 3.12 CGI 3.15 CGI::Carp 1.29 Algorithm::Diff 1.15 FileHandle 2.01 Optional Perl Modules CGI::Cookie 1.26 Text::Diff 0.35 CGI::Session 4.02 POSIX 1.09 MIME::Base64 3.07 Digest::SHA1 2.11 Digest::MD5 2.36 Locale::Maketext::Lexicon 0.55 Encode 2.12 PATH_INFO

For a URL such as http://ip address:83/foo/bar, the correct PATH_INFO is /foo/bar, without any prefixed path components. Click here to test this - particularly if you are using mod_perl, Apache or IIS, or are using a web hosting provider. Look at the new path info here. It should be /foo/bar. mod_perl Not used for this script

mod_perl is not loaded into Apache CGI user userid = iusr_fin-iis-02 groups = [Cannot identify groups - no Cygwin 'id' or 'sh' command on path]

Your CGI scripts are executing as this user. Original PATH C:\Perl\bin\;d:\ruby\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;D:\data\TWiki-4.0.1\lib

This is the PATH value passed in from the web server to this script - it is reset by TWiki scripts to the PATH below, and is provided here for comparison purposes only. Current PATH /bin:/usr/bin

This is the actual PATH setting that will be used by Perl to run programs. It is normally identical to {SafeEnvPath}, unless that variable is empty, in which case this will be the webserver users standard path..

Environment

-- ShawnBarrick - 04 Apr 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

I'm running the Perl application pool as the "Network Service" identity, and the site security as the default IIS anonymous user, though both have R/W permissions to the Perl and Twiki directories AFAIK.

-- ShawnBarrick - 04 Apr 2006

I assume IIS has some sort of error log. Is there any further information in there?

-- CrawfordCurrie - 05 Apr 2006

Yes: GET /twiki/bin/view.pl 502 2 0

"You receive this error message when you try to run a CGI script that does not return a valid set of HTTP headers"

-- ShawnBarrick - 05 May 2006

That sounds like your access log, rather thatn your error log. I was expecting to see a perl stack dump somewhere, or at least some kind of message suggesting why the headers came up short.

If you can, log in as the webserver user and run view.pl from the comment line (no parameters). And check that your permissions aallow the webserver user to execute the script.

-- CrawfordCurrie - 06 May 2006

I'm having the same issue. I've tracked it to the BEGIN {} statements. This PerlEx code and not Perl. By default ActivePerl assigns .pl to perl.exe "%s" %s and .plx to the PerlEx30.dll file.

I tried renaming view.pl to view.plx, but just got an error along the lines of "script returned no content".

After messing on some more I ended up remapping .pl to perlEx30.dll and then I could view pages. I am getting an error with the UserList and GroupList, but this is another issue.

-- StephenMoretti - 07 Jun 2006

An approach to get around this could be to try out the TWikiVMDebianStable, else you could try visiting TWikiIRC and get a few eyes on this in a realtime scenario.

-- SteffenPoulsen - 24 Jun 2006

Stephen, did you get the UserList and GroupList authenication problems fixed? I am currently at this stage and I'm stuck. Many thanks for any advice. Dan McAlister

-- DanielMcAlister - 13 Nov 2006

No follow-up, and the original q was answered, so closing this.

-- CrawfordCurrie - 16 Dec 2006

I've had this problem running Perl on IIS6 on MS Server 2003. For some reason, IIS6 thinks that the Headers are incomplete when they in fact aren't.

Here is a workaround that will force the "not incomplete" headers (and the generated page) to be sent to the client's browser (which will then execute them correctly)...

Underneath the perl shebang put: use CGI qw(:standard :cgi-lib); use CGI::Carp qw(fatalsToBrowser);

-- DarrenEveritt - 09 Nov 2007

I see that the guys ASPN say that IIS6 doesn't like the "/bin/" in the perl path!

-- DarrenEveritt - 09 Nov 2007

I changed the -wT switch to -w only and it was solved (tried a hello world program with -wT switch and had the same error), then you will face another error that setlib.cfg could not be found, but it will be if you add the absolute path to setlib.cfg

-- NorbertReuter - 16 Nov 2007 I am running IIS6 on Sever 2003 and the configure scripts runs fine (I had to change the she bang line to #!C:/Perl/Bin/Perl -w". But the main web page generates the "not complete" headers problem. If I run it from the command line "perl view.pl >x.html" then I can open x.html fine. In an editor, I can see that the end of the file is: "</body></html><p />". Hence the file is indeed not well formed. You cant have that final"</p>" can you? Also trying to use the fatalsToBrowser does generates Perl compile errors no matter what I do or what packages I install. Please help!The Event log reports nothing about this.

-- TWikiGuest - 10 Sep 2008

Hello Guest,

This question was closed some time ago. You will probably get a better response with a new (and open) question.

Also, please consider registering at TWiki.org. It's nice to know who we are corresponding with. It's not like we are getting paid to answer support questions

BTW, that "rogue <p />" is a known issue of TWiki 4.2.2. See KnownIssuesOfTWiki04x02 and TWikibug:Item5939

-- SeanCMorgan - 11 Sep 2008