CGI Error in Perl on IIS6

[Milo Minderbinder]

Hi,

I have Perl installed on both IIS5.1 and IIS6 (W2k3 Svr) and configured for
CGI processing of .cgi files (using "C:\perl\bin\perl.exe %s %s"). Most of
the scripts work fine on both , but a couple of them give me the following
result when view them via the IIS6 server:

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

These scripts both contain the lines "use XYZ;" but I'm not sure of the
issue that's causing. In both cases, the .pm and .pl library files are
located in the same directory as the non-working script.

Any suggestions? I haven't worked with Perl on IIS in quite some time, so
my knowledge of the config and tweaks are kinda hazy and probably outdated.

Thanks,
k

 

[Phil Frisbie, Jr.]

Hi,

I have Perl installed on both IIS5.1 and IIS6 (W2k3 Svr) and configured for
CGI processing of .cgi files (using "C:\perl\bin\perl.exe %s %s"). Most of
the scripts work fine on both , but a couple of them give me the following
result when view them via the IIS6 server:

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

These scripts both contain the lines "use XYZ;" but I'm not sure of the
issue that's causing. In both cases, the .pm and .pl library files are
located in the same directory as the non-working script.

Any suggestions?

The error is telling you exactly what needs to be fixed. Your script must return
a complete set of HTTP headers. IIS will not prepend a set of headers for you.

For example, you must at least return the content type as the first line like this:

print "Content-type: text/html\n\n";

 

[Alan J. Flavell]

I have Perl installed on both IIS5.1 and IIS6 (W2k3 Svr) and
configured for CGI processing of .cgi files (using
"C:\perl\bin\perl.exe %s %s"). Most of the scripts work fine on
both , but a couple of them give me the following result when view
them via the IIS6 server:

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

[...]

The error is telling you exactly what needs to be fixed.

Well, CGI scripts are supposed to return a *CGI response*, as
specified by the CGI specification (nowadays available as an
informational RFC, http://rfc.net/rfc3875.html )

The resemblance of a CGI response to HTTP headers is intentional - but
sometimes misleading. As I suspect we may be experiencing here.

Your script must return a complete set of HTTP headers. IIS will not
prepend a set of headers for you.

In the terms of the CGI specification, then, it would seem that you're
saying that this server treats the script as an "NPH" CGI script.
http://rfc.net/rfc3875.html#s5. refers.

Is that really the case? The servers that I'm accustomed to (Apache
and related) treat the normal case as parsed-headers scripts, which
are much easier to handle; NPH handling is exceptional, and has to be
asked for by choosing a particular naming pattern (nph-*) for the
script.

For example, you must at least return the content type as the first
line like this:

print "Content-type: text/html\n\n";

This is certainly good advice, if the content body is indeed HTML;
but in itself it is hardly a "complete set of HTTP headers".

I can't help worrying that the reference to "not returning a complete
set of HTTP headers" is an awkward way of saying the same thing that
Apache reports more accurately as "Premature end of script headers".

I just found a troubleshooting page at
http://www.microsoft.com/technet/archive/winntas/support/trouble.mspx
which says:

|| This error is caused by missing or incorrect CGI header
|| information.

(note their reference to *CGI* header - not HTTP header!), and:

||The CGI specification calls for the script file to return at least
||one header. This header indicates how to fill out the remainder of
||the HTTP headers as required by that protocol.

which seems to be MS's way of saying that the error message is
deliberately misleading. What it's looking for is an adequate set
of CGI response headers, and NOT the "complete set of HTTP headers"
that it wrongly specifies. That's how I read it, anyhow.

best regards

 

[David Wang [Msft]]

1. Run the Perl script on the commandline, to validate any syntax issues.
2. Since running script on commandline is insufficient proof that it runs by
the server (for example, process logon/identity are different [so privileges
differ], environment variables are not necessarily all set, and CGIs can
have arbitrary behavior for commandline vs web-server), try changing the
script name to prepend "nph-", and then request it from a web client to
obtain what the CGI *really* sent over the wire

Please provide the output of #2, where you run the script as nph, so that we
can see the output that is causing the 502 error for IIS6. You don't want to
use a browser for this because you want to know the RAW output, not the
parsed output by the browser client.

My suspicion is that the Perl script is outputing some plaintext error
response which does not conform to CGI specifications, and nph- output will
clarify that.

I would suggest against jumping to random conclusions like "they both
contain use XYZ; so that must be the problem". Any tweaks to make Perl run
on IIS is mostly with the adapter layer between Perl and IIS because Perl is
basically agnostic of the process invoking it, and IIS is agnostic of the
Engine/Process it invokes to handle a request. The adapter layer is
basically what glues them together and is where the tweaks happen. That
layer is usually provided with Perl packages to adapt Perl to various web
servers.

I really have not had problems just taking default stock Perl packages,
install it on Windows Server 2003, configure it as Perl package requires,
add the appropriate Application Mapping and Web Service Extension
configuration into IIS6, and then it works -- all pretty standard, simple,
documented stuff.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//