Perl cgi on Windows 2003 Server fails

Discussion in 'Perl Misc' started by Hallvard ?strem, Jun 9, 2004.

  1. My well tested Perl CGI scripts will not run on my web server after
    moving it from Windows NT 4.0 to a brand new Windows 2003 Server. The
    web server software is FirstClass Server 7.1 from Open Text Corp.
    (http://www.opentext.com/products/firstclass/), and the web server
    setup is identical with the setup on NT, which should be OK. Perl
    version on Windows 2003 Server is 5.806. Here are some of my
    observations:

    1. Scripts are running OK from the command prompt on the server, and
    the Perl installation looks OK. I've been through the more classical
    Perl for win32 pitfalls checks.

    2. Client browser returns this message:
    ---
    1.1 200 OK Server: FirstClass/7.1 Content-type: text/html Don't know
    how to run /cgi-bin/example.pl
    ---
    (Example.pl is a simple "Hello World" demo which runs OK from the
    prompt -- and normally on any web server with CGI-capabillity.)

    3. Compiled CGI scripts, e.g. EXE-files, runs OK on the server.

    4. Checked out the system PATH environment variable, and it points at
    C:\Perl\bin like it should.

    5. Web server service is set up with the Local System user account,
    and should have the proper access rights.

    6. I've installed an Apache test server in order to rule out the
    possibility that the problem somehow could be related to my FirstClass
    Server setup. The symptoms were almost identical, allthough Apache
    returned an not specified "Internal Server Error" message. Compiled
    CGI ran OK on Apache as well.

    In other words, there must be something in the Windows 2003 Server
    setup that I've missed? It seems like FirstClass Server can't find the
    Perl interpreter, even though the system PATH is OK. I've been through
    loads of FAQs and documentation, but haven't come across a solution so
    far. So I'll appreciate a helping hand on this.

    Regards,
    Hallvard Østrem
     
    Hallvard ?strem, Jun 9, 2004
    #1
    1. Advertising

  2. In article <>, Hallvard ?strem
    wrote:
    > My well tested Perl CGI scripts will not run on my web server after
    > moving it from Windows NT 4.0 to a brand new Windows 2003 Server. The
    > web server software is FirstClass Server 7.1 from Open Text Corp.
    > (http://www.opentext.com/products/firstclass/), and the web server
    > setup is identical with the setup on NT, which should be OK. Perl
    > version on Windows 2003 Server is 5.806. Here are some of my
    > observations:
    >
    > 1. Scripts are running OK from the command prompt on the server, and
    > the Perl installation looks OK. I've been through the more classical
    > Perl for win32 pitfalls checks.
    >
    > 2. Client browser returns this message:
    > ---
    > 1.1 200 OK Server: FirstClass/7.1 Content-type: text/html Don't know
    > how to run /cgi-bin/example.pl
    > ---
    > (Example.pl is a simple "Hello World" demo which runs OK from the
    > prompt -- and normally on any web server with CGI-capabillity.)
    >
    > 3. Compiled CGI scripts, e.g. EXE-files, runs OK on the server.
    >
    > 4. Checked out the system PATH environment variable, and it points at
    > C:\Perl\bin like it should.
    >
    > 5. Web server service is set up with the Local System user account,
    > and should have the proper access rights.
    >
    > 6. I've installed an Apache test server in order to rule out the
    > possibility that the problem somehow could be related to my FirstClass
    > Server setup. The symptoms were almost identical, allthough Apache
    > returned an not specified "Internal Server Error" message. Compiled
    > CGI ran OK on Apache as well.
    >
    > In other words, there must be something in the Windows 2003 Server
    > setup that I've missed? It seems like FirstClass Server can't find the
    > Perl interpreter, even though the system PATH is OK. I've been through
    > loads of FAQs and documentation, but haven't come across a solution so
    > far. So I'll appreciate a helping hand on this.
    >
    > Regards,
    > Hallvard Østrem


    I would suspect that the ".pl" file extension is not set system-wide, or you
    possibly need to define a "handler" (Apache term) for .pl files.

    Kevin
     
    Kevin Collins, Jun 9, 2004
    #2
    1. Advertising

  3. Thanks for your help, Kevin. The problem persists even if the server
    application runs as the current user, that is a user who can execute
    perl scripts from the DOS prompt.

    FirstClass CGI setup is quite simple and doesn't require any
    configuration other than the cgi-bin folder being installed in the
    appropriate folder on the file system. The script should execute as
    long as it finds the file in the cgi-bin path, and it does if it is
    e.g. a precompiled script.

    Since my server setup worked just fine on Windows NT, I'm quite sure
    my problem must be related to Perl/Windows 2003 Server somehow. Since
    Perl works fine from the prompt, I also believe it to be more likely
    related to the Windows 2003 Server setup, but how is still a mystery
    to me. I'm out of ideas...

    Hallvard


    (Kevin Collins) wrote in message news:<-guy.com>...
    > In article <>, Hallvard ?strem
    > wrote:
    > > My well tested Perl CGI scripts will not run on my web server after
    > > moving it from Windows NT 4.0 to a brand new Windows 2003 Server. The
    > > web server software is FirstClass Server 7.1 from Open Text Corp.
    > > (http://www.opentext.com/products/firstclass/), and the web server
    > > setup is identical with the setup on NT, which should be OK. Perl
    > > version on Windows 2003 Server is 5.806. Here are some of my
    > > observations:
    > >
    > > 1. Scripts are running OK from the command prompt on the server, and
    > > the Perl installation looks OK. I've been through the more classical
    > > Perl for win32 pitfalls checks.
    > >
    > > 2. Client browser returns this message:
    > > ---
    > > 1.1 200 OK Server: FirstClass/7.1 Content-type: text/html Don't know
    > > how to run /cgi-bin/example.pl
    > > ---
    > > (Example.pl is a simple "Hello World" demo which runs OK from the
    > > prompt -- and normally on any web server with CGI-capabillity.)
    > >
    > > 3. Compiled CGI scripts, e.g. EXE-files, runs OK on the server.
    > >
    > > 4. Checked out the system PATH environment variable, and it points at
    > > C:\Perl\bin like it should.
    > >
    > > 5. Web server service is set up with the Local System user account,
    > > and should have the proper access rights.
    > >
    > > 6. I've installed an Apache test server in order to rule out the
    > > possibility that the problem somehow could be related to my FirstClass
    > > Server setup. The symptoms were almost identical, allthough Apache
    > > returned an not specified "Internal Server Error" message. Compiled
    > > CGI ran OK on Apache as well.
    > >
    > > In other words, there must be something in the Windows 2003 Server
    > > setup that I've missed? It seems like FirstClass Server can't find the
    > > Perl interpreter, even though the system PATH is OK. I've been through
    > > loads of FAQs and documentation, but haven't come across a solution so
    > > far. So I'll appreciate a helping hand on this.
    > >
    > > Regards,
    > > Hallvard Østrem

    >
    > I would suspect that the ".pl" file extension is not set system-wide, or you
    > possibly need to define a "handler" (Apache term) for .pl files.
    >
    > Kevin
     
    Hallvard ?strem, Jun 11, 2004
    #3
  4. Hallvard ?strem

    Ben Morrow Guest

    Quoth (Hallvard ?strem):
    >
    > (Kevin Collins) wrote in message news:<-guy.com>...
    > > In article <>, Hallvard ?strem
    > > wrote:
    > > > My well tested Perl CGI scripts will not run on my web server after
    > > > moving it from Windows NT 4.0 to a brand new Windows 2003 Server.

    > >
    > > I would suspect that the ".pl" file extension is not set system-wide, or you
    > > possibly need to define a "handler" (Apache term) for .pl files.

    >
    > Thanks for your help, Kevin. The problem persists even if the server
    > application runs as the current user, that is a user who can execute
    > perl scripts from the DOS prompt.
    >
    > FirstClass CGI setup is quite simple and doesn't require any
    > configuration other than the cgi-bin folder being installed in the
    > appropriate folder on the file system. The script should execute as
    > long as it finds the file in the cgi-bin path, and it does if it is
    > e.g. a precompiled script.
    >
    > Since my server setup worked just fine on Windows NT, I'm quite sure
    > my problem must be related to Perl/Windows 2003 Server somehow. Since
    > Perl works fine from the prompt, I also believe it to be more likely
    > related to the Windows 2003 Server setup, but how is still a mystery
    > to me. I'm out of ideas...


    What happens if you create a file script.pl and double-click on it? Does
    it run with perl, or not? You haven't yet indicated that it does.

    Ben

    --
    If I were a butterfly I'd live for a day, / I would be free, just blowing away.
    This cruel country has driven me down / Teased me and lied, teased me and lied.
    I've only sad stories to tell to this town: / My dreams have withered and died.
    (Kate Rusby)
     
    Ben Morrow, Jun 11, 2004
    #4
  5. Have you checked the Web Security extensions (think that is the correct
    lingo) in IIS on your 2003 server? Out of the box, the latest IIS is very
    gimped as far as what it will let execute. Look in the IIS manager, on the
    left side it is listed there then the options of what to allow/disallow are
    shown in the right pane.

    "Hallvard ?strem" <> wrote in message
    news:...
    > Thanks for your help, Kevin. The problem persists even if the server
    > application runs as the current user, that is a user who can execute
    > perl scripts from the DOS prompt.
    >
    > FirstClass CGI setup is quite simple and doesn't require any
    > configuration other than the cgi-bin folder being installed in the
    > appropriate folder on the file system. The script should execute as
    > long as it finds the file in the cgi-bin path, and it does if it is
    > e.g. a precompiled script.
    >
    > Since my server setup worked just fine on Windows NT, I'm quite sure
    > my problem must be related to Perl/Windows 2003 Server somehow. Since
    > Perl works fine from the prompt, I also believe it to be more likely
    > related to the Windows 2003 Server setup, but how is still a mystery
    > to me. I'm out of ideas...
    >
    > Hallvard
    >
    >
    > (Kevin Collins) wrote in message

    news:<-guy.com>...
    > > In article <>, Hallvard

    ?strem
    > > wrote:
    > > > My well tested Perl CGI scripts will not run on my web server after
    > > > moving it from Windows NT 4.0 to a brand new Windows 2003 Server. The
    > > > web server software is FirstClass Server 7.1 from Open Text Corp.
    > > > (http://www.opentext.com/products/firstclass/), and the web server
    > > > setup is identical with the setup on NT, which should be OK. Perl
    > > > version on Windows 2003 Server is 5.806. Here are some of my
    > > > observations:
    > > >
    > > > 1. Scripts are running OK from the command prompt on the server, and
    > > > the Perl installation looks OK. I've been through the more classical
    > > > Perl for win32 pitfalls checks.
    > > >
    > > > 2. Client browser returns this message:
    > > > ---
    > > > 1.1 200 OK Server: FirstClass/7.1 Content-type: text/html Don't know
    > > > how to run /cgi-bin/example.pl
    > > > ---
    > > > (Example.pl is a simple "Hello World" demo which runs OK from the
    > > > prompt -- and normally on any web server with CGI-capabillity.)
    > > >
    > > > 3. Compiled CGI scripts, e.g. EXE-files, runs OK on the server.
    > > >
    > > > 4. Checked out the system PATH environment variable, and it points at
    > > > C:\Perl\bin like it should.
    > > >
    > > > 5. Web server service is set up with the Local System user account,
    > > > and should have the proper access rights.
    > > >
    > > > 6. I've installed an Apache test server in order to rule out the
    > > > possibility that the problem somehow could be related to my FirstClass
    > > > Server setup. The symptoms were almost identical, allthough Apache
    > > > returned an not specified "Internal Server Error" message. Compiled
    > > > CGI ran OK on Apache as well.
    > > >
    > > > In other words, there must be something in the Windows 2003 Server
    > > > setup that I've missed? It seems like FirstClass Server can't find the
    > > > Perl interpreter, even though the system PATH is OK. I've been through
    > > > loads of FAQs and documentation, but haven't come across a solution so
    > > > far. So I'll appreciate a helping hand on this.
    > > >
    > > > Regards,
    > > > Hallvard Østrem

    > >
    > > I would suspect that the ".pl" file extension is not set system-wide, or

    you
    > > possibly need to define a "handler" (Apache term) for .pl files.
    > >
    > > Kevin
     
    Eric Stanfield, Jun 12, 2004
    #5
  6. Hallvard ?strem

    ChrisO Guest

    Hallvard ?strem wrote:
    > Thanks for your help, Kevin. The problem persists even if the server
    > application runs as the current user, that is a user who can execute
    > perl scripts from the DOS prompt.
    >
    > FirstClass CGI setup is quite simple and doesn't require any
    > configuration other than the cgi-bin folder being installed in the
    > appropriate folder on the file system. The script should execute as
    > long as it finds the file in the cgi-bin path, and it does if it is
    > e.g. a precompiled script.
    >
    > Since my server setup worked just fine on Windows NT, I'm quite sure
    > my problem must be related to Perl/Windows 2003 Server somehow. Since
    > Perl works fine from the prompt, I also believe it to be more likely
    > related to the Windows 2003 Server setup, but how is still a mystery
    > to me. I'm out of ideas...
    >
    > Hallvard
    >


    I, for one, would be a little curious as to which Perl you are running
    as well. The symptoms you've described don't directly implicate the
    version of Perl, but I'm curious nonetheless. The version you specified
    doesn't sound like ActiveState Perl which I consider to be the de facto
    standard in the Windows world. Your Perl of course wouldn't *have* to
    be ASPN in order to work, hence my curiosity.

    -ceo
     
    ChrisO, Jun 12, 2004
    #6
  7. Perl version is ActiveState 5.8.0 for Win32.

    *.pl files execute just fine from the prompt or by clicking in
    Windows. In other words, system path and file associations should be
    OK.

    IIS is not installed on the server at all, as long as I'm not
    intending to use it. My FirstClass Server provides SMTP and POP3 as
    well as web services, and it should not depend on Windows IIS -- if
    that's the case, that would be a shame. At least, this was not the
    case in Windows NT 4.0 where an identical web server setup has been
    delivering CGI for years.

    The big question is what could be the difference between NT and 2003
    in this respect, when everything else is identical?

    I've been wondering a bit about MIME, but have not experienced before
    that FCS CGI were depending on MIME definitions (...like in Apache.
    Nevertheless, a test installation of Apache shows the same symptoms --
    Perl CGI scripts don't run). A few experiments in that direction were
    not very successfull either. And again, my MIME configuration didn't
    create any problems for CGI scripts on Windows NT.

    Anyone having an Apache installation on Windows 2003 Server with a
    working Perl CGI setup?

    ChrisO <> wrote in message news:<cqLyc.1022$>...
    > Hallvard ?strem wrote:
    > > Thanks for your help, Kevin. The problem persists even if the server
    > > application runs as the current user, that is a user who can execute
    > > perl scripts from the DOS prompt.
    > >
    > > FirstClass CGI setup is quite simple and doesn't require any
    > > configuration other than the cgi-bin folder being installed in the
    > > appropriate folder on the file system. The script should execute as
    > > long as it finds the file in the cgi-bin path, and it does if it is
    > > e.g. a precompiled script.
    > >
    > > Since my server setup worked just fine on Windows NT, I'm quite sure
    > > my problem must be related to Perl/Windows 2003 Server somehow. Since
    > > Perl works fine from the prompt, I also believe it to be more likely
    > > related to the Windows 2003 Server setup, but how is still a mystery
    > > to me. I'm out of ideas...
    > >
    > > Hallvard
    > >

    >
    > I, for one, would be a little curious as to which Perl you are running
    > as well. The symptoms you've described don't directly implicate the
    > version of Perl, but I'm curious nonetheless. The version you specified
    > doesn't sound like ActiveState Perl which I consider to be the de facto
    > standard in the Windows world. Your Perl of course wouldn't *have* to
    > be ASPN in order to work, hence my curiosity.
    >
    > -ceo
     
    Hallvard ?strem, Jun 14, 2004
    #7
  8. Hallvard ?strem

    ChrisO Guest

    l v wrote:
    > Hallvard ?strem wrote:
    >
    >> Perl version is ActiveState 5.8.0 for Win32.
    >> *.pl files execute just fine from the prompt or by clicking in
    >> Windows. In other words, system path and file associations should be
    >> OK.
    >>
    >> IIS is not installed on the server at all, as long as I'm not
    >> intending to use it. My FirstClass Server provides SMTP and POP3 as
    >> well as web services, and it should not depend on Windows IIS -- if
    >> that's the case, that would be a shame. At least, this was not the
    >> case in Windows NT 4.0 where an identical web server setup has been
    >> delivering CGI for years.
    >>
    >> The big question is what could be the difference between NT and 2003
    >> in this respect, when everything else is identical?
    >>
    >> I've been wondering a bit about MIME, but have not experienced before
    >> that FCS CGI were depending on MIME definitions (...like in Apache.
    >> Nevertheless, a test installation of Apache shows the same symptoms --
    >> Perl CGI scripts don't run). A few experiments in that direction were
    >> not very successfull either. And again, my MIME configuration didn't
    >> create any problems for CGI scripts on Windows NT.
    >>
    >> Anyone having an Apache installation on Windows 2003 Server with a
    >> working Perl CGI setup?
    >>
    >> ChrisO <> wrote in message
    >> news:<cqLyc.1022$>...
    >>
    >>> Hallvard ?strem wrote:
    >>>
    >>>> Thanks for your help, Kevin. The problem persists even if the server
    >>>> application runs as the current user, that is a user who can execute
    >>>> perl scripts from the DOS prompt.
    >>>>
    >>>> FirstClass CGI setup is quite simple and doesn't require any
    >>>> configuration other than the cgi-bin folder being installed in the
    >>>> appropriate folder on the file system. The script should execute as
    >>>> long as it finds the file in the cgi-bin path, and it does if it is
    >>>> e.g. a precompiled script.
    >>>>
    >>>> Since my server setup worked just fine on Windows NT, I'm quite sure
    >>>> my problem must be related to Perl/Windows 2003 Server somehow. Since
    >>>> Perl works fine from the prompt, I also believe it to be more likely
    >>>> related to the Windows 2003 Server setup, but how is still a mystery
    >>>> to me. I'm out of ideas...
    >>>>
    >>>> Hallvard
    >>>>
    >>>
    >>> I, for one, would be a little curious as to which Perl you are
    >>> running as well. The symptoms you've described don't directly
    >>> implicate the version of Perl, but I'm curious nonetheless. The
    >>> version you specified doesn't sound like ActiveState Perl which I
    >>> consider to be the de facto standard in the Windows world. Your Perl
    >>> of course wouldn't *have* to be ASPN in order to work, hence my
    >>> curiosity.
    >>>
    >>> -ceo

    >
    >
    > If perl is running correctly via command line or explorer then your
    > problem is not in windows but in your web server configuration.
    >
    > In reading the online documentation on your behalf:
    > http://www.firstclass.com/FirstClas...tion/Online Books/Internet Services guide.pdf
    >
    >
    > page 158 "Adding a CGI script" step 4 "Follow the information contained
    > in the CGI ReadMe to configure your executable."
    >
    > I do not have Firstclass so I can not give you the solution.
    >


    Or the behavior of FC changed inbetween WNT 4.0 and W2K3... More than
    likely, if Perl is acting fine on the command line. That's *my* guess.
    Last time I used FC was in 1993, so that's about as well as I can do
    with this. I haven't run into very many FC users in a while, so you
    (the OP) may be a bit stuck. FC is kinda off the beaten path... :(

    -ceo
     
    ChrisO, Jun 15, 2004
    #8
  9. Problem finally solved.

    A "ScriptMap" key was missing in the Windows 2003 Server registry, and
    a reinstallation of Perl fixed it. Perl was originally installed
    BEFORE the FirstClass Server software on the server, and this produced
    the situation with this particular registry entry missing.

    [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\FCS\Parameters\ScriptMap]
    ".pl"="C:\\Perl\\bin\\perl.exe %s %s"

    (FCS=FirstClass Server)

    A reinstallation of Perl will get it right.

    Thanks for all your help!
    Hallvard

    ChrisO <> wrote in message news:<setzc.1568
    >
    > Or the behavior of FC changed inbetween WNT 4.0 and W2K3... More than
    > likely, if Perl is acting fine on the command line. That's *my* guess.
    > Last time I used FC was in 1993, so that's about as well as I can do
    > with this. I haven't run into very many FC users in a while, so you
    > (the OP) may be a bit stuck. FC is kinda off the beaten path... :(
    >
    > -ceo
     
    Hallvard ?strem, Jun 16, 2004
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kieran Kelly
    Replies:
    3
    Views:
    853
    Shaji
    Sep 29, 2003
  2. Juan T. Llibre [MVP]
    Replies:
    4
    Views:
    3,008
    Patrick Olurotimi Ige
    Dec 9, 2004
  3. Jeremy Holt
    Replies:
    0
    Views:
    489
    Jeremy Holt
    Apr 1, 2005
  4. kath
    Replies:
    4
    Views:
    652
    J. Gleixner
    Apr 9, 2007
  5. Replies:
    1
    Views:
    139
    Ian Wilson
    Jun 15, 2007
Loading...

Share This Page