Running CGI through browser from local hard disk

Discussion in 'Perl Misc' started by Dr. John P. Costella, Jul 16, 2003.

  1. Hi folks, this probably has a simple answer ... I'm new to Perl so
    please be gentle. :)

    I am trying to test what a browser would show when accessing a CGI
    script, but without going through an actual server. I have Perl
    running fine on the local machine (Win XP) and am working through some
    tutorials etc. But if I try to access the file through MSIE it runs
    the script from a command prompt rather than piping the result back to
    the browser.

    Is this possible to do without the actual server? (I intend to put the
    final working script onto a real server down the track, but for
    various reasons that's not possible at this time.)

    Thanks greatly for any help.

    John Costella
     
    Dr. John P. Costella, Jul 16, 2003
    #1
    1. Advertisements

  2. Dr. John P. Costella

    Bob Walton Guest

    Dr. John P. Costella wrote:

    ....
    What do you have against running a local server? Here is one in Perl if
    you don't have one:

    use HTTP::Daemon;
    use IPC::Open2;
    $|=1;
    my $server=HTTP::Daemon->new(LocalPort=>80,LocalAddr=>'localhost');
    print "Please contact me at <URL:", $server->url, ">\n";
    while($client=$server->accept){
    while(my $answer=$client->get_request){
    $ans=$answer->as_string;
    @ans=split /\n/,$ans;
    $client->autoflush;
    if($answer->method eq 'GET'){
    $path=$answer->url->path;
    (error,last) unless $path=~s#^/##;
    if($path=~/html$/i){
    $client->send_file_response($path);
    last;
    }
    if($path=~/cgi$/i){
    $ENV{REQUEST_METHOD}=$answer->method;
    $query=$answer->url->query;
    $ENV{CONTENT_LENGTH}=length($query);
    $ENV{QUERY_STRING}=$query;
    $out=`perl $path`;
    $out=~s/.*?\n\n//s; #remove HTTP header
    print $client $out;
    last;
    }
    }
    if($answer->method eq 'POST'){
    $path=$answer->url->path;
    (error,last) unless $path=~s#^/##;
    if($path=~/cgi$/i){
    $query=$answer->url->query;
    $ENV{REQUEST_METHOD}=$answer->method;
    for(@ans){
    $ENV{CONTENT_LENGTH}=$1 if /Content-Length: (\d+)/;
    $ENV{HTTP_REFERRER}=$1 if /Referer: (.*)/;
    }
    $query=$ans[-1];
    undef $CGI;undef $OUT;
    $pid=open2($CGI,$OUT,"perl","$path") or error;
    print $OUT $query;
    close $OUT;
    @out=<$CGI>;
    waitpid $pid,0;
    $out=join "\n",@out;
    $out=~s/.*?\n\n//s; #remove HTTP header
    print $client $out;
    last;
    }
    }
    last;
    }
    print "CLOSE: ", $client->reason, "\n" if $client->reason;
    undef $client;
    }

    sub error{
    $client->error(RC_FORBIDDEN);
    print "An error occurred in $ans\n";
    }
     
    Bob Walton, Jul 16, 2003
    #2
    1. Advertisements

  3. Try here: http://www.xarka.com/optiperl/index.html it has a trial
    download and I think it's $29 to buy. You may also do a search on
    http://download.com.com I know I used to use one that had a separate
    window to show you what the CGI would look like in a Browser. (I think
    it was the OptiPerl above.

    Jeremy Fluhmann
    McLane Information Systems
     
    Jeremy Fluhmann, Jul 16, 2003
    #3
  4. Dr. John P. Costella

    Cat Guest

    It is a security risk to allow your browser to execute external commands
    and is the reason why good browsers (forget MSIE) do not permit such behaviour.
     
    Cat, Jul 16, 2003
    #4
  5. Dr. John P. Costella

    Tony Curtis Guest

    On 18 Jul 2003 13:14:39 -0800,
    Yeah, but there are other considerations. The most
    obvious one is that of the userid and environment under
    which CGI programs would execute, rather than as yourself
    at the command-line.

    But I fear this is drifting way off-topic for clpm.

    hth
    t
     
    Tony Curtis, Jul 18, 2003
    #5
  6. IMO, testing from the command line is something the OP should be doing
    before deployment on a CGI server.

    BTW, when you save to an HTML file, you may wish to comment out the header
    shortcut in your script, so you can open the file with your browser to see
    it as it would look in a browser, e.g.,

    #!perl -w
    # webcam_gallery.pl - command line version
    # usage - perl webcam_gallery.pl > webcam_show.htm
    use strict;
    use CGI qw:)standard);
    print
    # header,
    start_html;
    # rest of script

    Cheers.

    Bill Segraves
     
    William Alexander Segraves, Jul 18, 2003
    #6
  7. Gunnar Hjalmarsson () wrote:
    : Dr. John P. Costella wrote:
    : > I am trying to test what a browser would show when accessing a CGI
    : > script, but without going through an actual server.

    : Well, you do need a server.

    Not really, though that is easiest in the long run.

    He could simply go to the command line and run the script with the desired
    parameters and save the output in a file.

    C:> perl my-cgi.pl submit=doit the_field=test-value > temp.htm

    and then browse that file (temp.htm) to check what it looked like.
     
    Malcolm Dew-Jones, Jul 18, 2003
    #7
  8. Why? If you direct the exception messages to the browser, which is
    kind of natural when developing CGI scripts, personally I find 'the
    CGI way' to be more convenient.
     
    Gunnar Hjalmarsson, Jul 18, 2003
    #8
  9. ISTM we're not talking (writing) about the same scenario. While the headers
    cause no problems when served by a CGI server; they do cause problems when
    they are at the top of an HTML file that is opened with MSIE. That's why I
    commented out the header shortcut in the example I posted for the command
    line version of a working script.

    YMMV.

    Cheers.

    Bill Segraves
     
    William Alexander Segraves, Jul 19, 2003
    #9
  10. Hi, Gunnar.

    It appears to be a matter of personal preference. Personally, I prefer to do
    my syntax checking from the command line. Why would I want to run a broken
    script on a CGI server?

    In a literal sense, it appears the OP wants "without going through an actual
    server".

    Cheers.

    Bill Segraves
     
    William Alexander Segraves, Jul 19, 2003
    #10
  11. William Alexander Segraves () wrote:
    : : <snip>
    : > I have never found that necessary. It's true the headers are displayed at
    : > the top, but otherwise they do not interfere with the html in any way I
    : > have ever noticed.
    : >

    : ISTM we're not talking (writing) about the same scenario. While the headers
    : cause no problems when served by a CGI server; they do cause problems when
    : they are at the top of an HTML file that is opened with MSIE. That's why I
    : commented out the header shortcut in the example I posted for the command
    : line version of a working script.

    : YMMV.

    : Cheers.

    : Bill Segraves

    Something in our setups must be different then.

    I have opened many files (i.e. local files, e.g. C:\try.htm) with MSIE of
    various versions, and have not found that mime like headers at the top of
    the file make any difference to the display, except as appearing as lines
    of text at the top of the window.
     
    Malcolm Dew-Jones, Jul 19, 2003
    #11
  12. Well, yes. That was exactly my point. The text I did not wish to appear at
    the top of the HTML displayed in the (MSIE5.5) browser was the Content-Type
    header, e.g., for the script fragment I posted,

    Content-Type: text/html; charset=ISO-8859-1

    Note that this is not a problem in a CGI environment; but rather, is only a
    problem when generating the HTML from the command line. Indeed, the
    Content-Type header *must* be present in the CGI environment. Without it, we
    get an "Internal Server Error" message in the browser window.

    Malcolm, I think we are in agreement. As these issues are off-topic for
    clpm, we could leave the thread here (or move it to ciwac, where IMO, it
    *should* have been posted).

    Cheers.

    Bill Segraves
     
    William Alexander Segraves, Jul 19, 2003
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.