CGI Error: explanation needed..

more info:

the IIS server runs in Win NT Server 4.0

your CGI did not produce a header like:

Content-Type: text/html\n\n

3Mann,

yes ahoffmann is likely to be correct here look at the presence of a content line.

Content-Type: text/html\n\n

Fialing this make sure you have the correct permissions and the path to perl is correct.

or the path to perl is correct, ie check /usr/bin/perl or whatever you have actually points to perl.


If all these fail, make sure a basic cgi perl works on your server: ie

#!/usr/bin/perl

print "Content-Type: text/html\n\n";
print "Hello World";


let me know how you get on..
regards
Peewee

I think it is more likely that execution of the CGI failed completely.

Had it output anything then I would expect it to appear within the error message even if it wasn't a valid header.

Moreover I don't thnik IIS actual checks the HTTP header message passed by a CGI. But what it does detect is that the CGI has 'ended' without outputting anything.

3Mann,
did you get the answer u were looking for?

regards Peewee

hi guys,
isn't it a problem with the IIS settings?

i tried it before and it was running, though now, the program i installed would output that error.
i couldn't do anything though regarding CGI/perl since its a third-party program and can't do any CGI recoding for that.

i tried ticking the checkbox for allowing execution of scripts but still the error is the same.

3Mann,

assuming your IIS setting are correct then the problem will be either:

A:
===============================
your path to perl is incorrect:

#!/usr/bin/perl

print "Content-Type: text/html\n\n";
print "Hello World";

in the example here perl is expected to be at /usr/bin/perl on a unix system or C:\usr\bin\perl.exe on a windows system.

Solution:
for unix simple do a perl -v for windows check where the perl.exe is located.

B:
incompatable Line endings:
Windows and Unix have different line endings, make sure that if you ftp your program anywhere you have the correct settings, for line endings and ASCII for scripts or binary for images. This problem may occur if you have developed
 on one machine and are planning to run your scripts on another.

Here's what to do:
execute this script below and ensure permissions are 775 the line endings are correct for the operating stystem and
perl is located where the cgi script is teliing the server.


let me know how you get on..
reagrds Peewee

ftp ASCII mode is not reliable, make shure the file is in correct format on the sender, then ftp it using bin mode.

>ftp ASCII mode is not reliable

Absolute nonsense.

mouatts, try following in a file:

   print "enclosed in ' is a real newline 'NL' character";

(NL means: 0x0a)
then transfer (probably from a Windoze ftp client) the file in ASCII mode, and rethink your statement

I presume you mean to a windows machine. But yes it will convert to CRLF. But that is perfectly correct because you have effectively created the file as a 'binary file'. Within your example this would be correct because 0x0A is NOT a real newline character it is the Linefeed character (considering LF to be a newline character is very much a unixism) . By converting it the result would actually be correct on each machine - 0A on Unix and 0D0A on Windows etc.

Transfer your example to a windows machine via binary and it won't work, but this doesn't mean that the binary mode is unreliable just that you have used the wrong format!

Making the decision to use either Binary or ASCII mode does require you to know the format of the file that you are going to transfer. Most languages support character constants and programmers should use them to avoid the potential problems caused by using the numeric equivelents. Having said that it is a great shame that Perl/C etc don't support \l for a linefeed forcing you to use \0x0a.

Steve

i appreciate all the answers guys but i was merely installing a software =D

i read the SW requirements of the product and its reqs are only NTServer and IIS.  No mention of perl.exe or any other.  Am i missing something?

Sorry for my naiveity... =D

cheers,
3Mann

3Mann, sorry for being off-topic.

> read the SW requirements of the product and its reqs are only NTServer and IIS.
And in which language/type are your CGIs? Could you please check in your cgi-bin directory.

If the cgi is an exe make sure that the user under which IIS runs has execute permissions on the program and that within IIS execute permission is turned on for the directory in which the cgi is stored.

Steve

3Mann,

in my first post i wrote:

#!/usr/bin/perl

print "Content-Type: text/html\n\n";
print "Hello World";


make this into a program and run in and see what happens, this will tewst if your server is ok with CGI.

You would be well advised to rule this out first of all.  You of course will need perl.exe installed on your machine, and for this script it is expected at c:\usr\bin\perl.exe

If it is anywhere else this script will not work.


try this and report back exatly what you see. Thius may sound silly be this will save you you an awful lot of time an effort.

regards Peewee

3Mann,

did u get the answer u were looking for?

regards Peewee

3Mann,

did u get the answer u were looking for?

if so, would you care to share your solution with us?

regards Peewee

hmm, that's exactly what I said in http:#7137280

Sorry guys.  Was just able to come back to this question just now.

regarding the question of peewee:
>did u get the answer u were looking for?
>if so, would you care to share your solution with us?

i actually had this problem when using the client-server antivirus software.
there was no solution as we just used another software.

now how do i give points to this?