crux_007 has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

I am working on implementing the cgi perl scripts in IIS. I made the initial mapping of .cgi and .pl extension to perlis.dll. I tested it by running the scripts in the IIS and accessed that from other client systems and it works fine.

The problem I have is that when I post form value using the submit button and send it from a html to perl script, I receive no data in this variable "$ENV{'QUERY_STRING'}". Also the HTTP statement "Content-type: text/html" is getting displayed in the web browser of the client machines.

If you have any ideal to solve this issue please post your comments.

Thanks

Replies are listed 'Best First'.
Re: CGI PERL and IIS
by Ovid (Cardinal) on Dec 04, 2005 at 09:38 UTC

    Can you post some of your code? If you use the POST method, $ENV{QUERY_STRING} won't have any data. However, if you are using the CGI.pm module or something similar, you won't even have to worry about that. As for why your content type is getting displayed in the browser, it's tough to say. Again, posting some code will help. I have a link below to my CGI course. You might find that helpful.

    Cheers,
    Ovid

    New address of my CGI Course.

Re: CGI PERL and IIS
by serf (Chaplain) on Dec 04, 2005 at 10:37 UTC
    HTTP headers, like email headers are distinguished from the body part of the returned data by an empty line (equivalent of 'print "\n\n"')

    If you find "Content-type: text/html" or any other text string which you were expecting to be part of the page header being displayed at the top of the page before the contents of the page (i.e. in the body instead of being in the header) there is a good chance that the webserver is returning a blank line before your "Content-type: text/html" line is being output by your script.

    This is often due to something like:

    print qq~ Content-type: text/html ... (more headers) (body) ~;
    If you're using print qq~... bear in mind that it prints everything between the double quote markers (in this case the tilde characters) unlike using
    print <<EOT; Content-type: text-html ... (more headers) (body) EOT
    which starts printing everthing after the print <<EOT; line. I sometimes found in the past that I'd done that when I'd converted over from a "print it as it looks in the code" print delimiter to quoted data.

    You can fix this by putting the first line of the headers immediately after the ~ like this:

    print qq~Content-type: text-html ... (more headers)
    You can test the output of the server by using a web client that will dump the page with headers (like curl -i  http://myhost/ or lynx -mime_header http://myhost/ if you have access to either curl or lynx, or even by telnetting to the web port and typing in the GET command manually (if you know what you need to send to get the page you want - easy with HTTP/1.0 but maybe a bit more complicated with virtual hosts and HTTP/1.1 requests.)

    If you have GET installed you can use GET -e http://myhost/ otherwise you could use a short perl script to return the entire contents - something like this:

    #!/usr/bin/perl use strict; use warnings; use LWP::UserAgent; my $ua = LWP::UserAgent->new; my $url = shift; die "Usage: $0 URL\n" unless($url); my $response = $ua->get($url); die $response->status_line, $/ unless ($response->is_success); print $response->headers_as_string, $/, $response->content;
    (If anybody would like to golf this example feel free - it could be great to have a one liner up one's sleeve for this!) ;o)
Re: CGI PERL and IIS
by jonadab (Parson) on Dec 04, 2005 at 12:06 UTC
    I receive no data in this variable "$ENV{'QUERY_STRING'}"

    In the form element of the html file, what is the value of the method attribute? It should be either "get" or "post". If it's "get", your form data should come in via $ENV{QUERY_STRING}, but if it's "post", then your form data should come in via standard input and will be formatted somewhat differently. I think CGI specifies how this works, so it should be largely the same in IIS as it is in Apache, although I haven't worked much with IIS so there could be minor differences I don't know about.