Perl and IIS - script runs but 'The page cannot be displayed'

[stew dean]

This is not a pure Perl problem but is to do with the running of Perl
on IIS.

I now have two scripts that run without errors (I'm using strict) but,
for some reason, will not display the simple 'Done!' page built into
the script. Instead the server gives me 'The page cannot be
displayed'.

I have run it on a local IIS set up with no problems but on the main
server I continue to get this error. As I have no error messages other
than page not displayed I'm not sure what I can tweak to get it to
work. Maybe there's an error log I could look at?

I need to get a HTML page displayed at the end so I can then do futher
steps but so far cannot.

I'm running ActiveState Perl 5.8 with IIS 5 on a Windows 2000 box.

Any help appreciated.

Stew Dean

 

[A. Sinan Unur]

(e-mail address removed) (stew dean) wrote in

This is not a pure Perl problem but is to do with the running of Perl
on IIS.

I now have two scripts that run without errors (I'm using strict) but,
for some reason, will not display the simple 'Done!' page built into
the script. Instead the server gives me 'The page cannot be
displayed'.

And we are supposed to divine what is going on without seeing a line of
code?

I have run it on a local IIS set up with no problems but on the main
server I continue to get this error. As I have no error messages other
than page not displayed I'm not sure what I can tweak to get it to
work. Maybe there's an error log I could look at?

There probably is. Why don't you look at it?

I need to get a HTML page displayed at the end so I can then do futher
steps but so far cannot.
....

Any help appreciated.

To get any help, you'll need top provide some information. Also, make
sure this is not a web server configuration or CGI issue. Please refer to
the posting guidelines for this group at

http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

Without at least seeing a short example script that illustrates the
problem you are having, it is impossible to say anything.

Sinan.

 

[James Willmore]

On 21 Oct 2003 03:53:24 -0700

This is not a pure Perl problem but is to do with the running of
Perl on IIS.

I now have two scripts that run without errors (I'm using strict)
but, for some reason, will not display the simple 'Done!' page built
into the script. Instead the server gives me 'The page cannot be
displayed'.

I have run it on a local IIS set up with no problems but on the main
server I continue to get this error. As I have no error messages
other than page not displayed I'm not sure what I can tweak to get
it to work. Maybe there's an error log I could look at?

This questions begs one to ask - "Did you read the documentation for
IIS?". Errors from your script _should_ be there for you to examine.

I need to get a HTML page displayed at the end so I can then do
futher steps but so far cannot.

I'm running ActiveState Perl 5.8 with IIS 5 on a Windows 2000 box.

Any help appreciated.

Please start by RTM Also, run the script at the command line.
Any errors should show there - and be identical (with all things being
equal) to the error messages in the error log.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
In English, every word can be verbed. Would that it were so in
<our programming languages.

 

[Roy Johnson]

I now have two scripts that run without errors (I'm using strict) but,
for some reason, will not display the simple 'Done!' page built into
the script. Instead the server gives me 'The page cannot be
displayed'.

Perhaps the server is not configured to run scripts? Or, if you know
that the scripts are running, the page won't display, you must have a
problem with formatting (maybe you're not sending the "text/html"
prologue?).

In that case, try shift-clicking the link that launches the scripts,
so you can save the output to a file, then peruse the file. Name it
with a .html extension and try to load it directly.

 

[stew dean]

(e-mail address removed) (stew dean) wrote in


And we are supposed to divine what is going on without seeing a line of
code?

The code it's self, although clunky no doubt compared to the abilities
of many, works fine. It's processing a large XML file and spitting out
webpages. With a smaller XML file it displays Done - with a larger one
it apears to time out. I've checked it for errors by putting a dummy
error in there but it only shows up that error.

There probably is. Why don't you look at it?

I don't know if there is an error log or where it would be if there
was. Any suggestions suggested.

To get any help, you'll need top provide some information. Also, make
sure this is not a web server configuration or CGI issue. Please refer to
the posting guidelines for this group at

http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

Without at least seeing a short example script that illustrates the
problem you are having, it is impossible to say anything.

The script is fine. I have many scripts running quite happily except
for the two hardest working scripts, both are fine when you give them
a short XML file but large ones cause problems. The server is hefty
enough to handle them (memory etc is all fine) so I'm thinking it's a
set up issue with IIS.

I'm looking to see if anyone else has a similair problem.

Stew Dean

 

[stew dean]

On 21 Oct 2003 03:53:24 -0700


This questions begs one to ask - "Did you read the documentation for
IIS?". Errors from your script _should_ be there for you to examine.

The errors for the script are not going to be in the documentation. I
have a rather hefty manual I could spend a few weeks reading but I
very much doubt it will resolve my issue.

Please start by RTM Also, run the script at the command line.
Any errors should show there - and be identical (with all things being
equal) to the error messages in the error log.

When it comes down to the combination of technolgies i'm using the
manuals don't cut it. The perl ones are aimed at Unix users and the
IIS help files don't (help that is). I have some heft books on IIS
and, quite frankly, it's a soul destoying paper chase form tech term
to tech term.

I've been online for about nine years now - the interweb superexpress
freeway always delivers answers that dead tree media often cannot. I
wouldnt ask if it the solution was in the pile of vegetable cells on
my desk.

Stew Dean

 

[A. Sinan Unur]

(e-mail address removed) (stew dean) wrote in

The errors for the script are not going to be in the documentation. I
have a rather hefty manual I could spend a few weeks reading but I
very much doubt it will resolve my issue.

The manual would tell you where to find the error logs so you can find
out what is wrong, and maybe give us a clue. That is not too much to ask.

I've been online for about nine years now - the interweb superexpress
freeway always delivers answers that dead tree media often cannot. I
wouldnt ask if it the solution was in the pile of vegetable cells on
my desk.

So, you cannot be bothered to check the error logs, and tell us what is
in there, but somehow we are supposed to divine what is going on ...
Interesting attitude.

In the time you took to type up all these replies as to why you won't
check the error logs, you could have checked the error logs, and posted
some information that could have been helpful in figuring out the
problem.

 

[James Willmore]

On 22 Oct 2003 04:27:54 -0700
<snip>

What happened when you ran the script at the command line? There is
_little_ difference between running the script on the command line and
running it through the web server - especially if you use the CGI
module (hint - '-debug').

Where is the code you speak of? You have yet to post any offending
code.

The documentation for _Perl_ (specifically, perlfaq9) gives a tip or
two on debugging a buggy Perl CGI script.

And yes, I was insulting to you. Sorry for the transgression. By the
same token, if you run a web server, you should at least know where
the logs are located - or you shouldn't be a web server admin or even
touch a web server for development purposes. I may not agree with
some of the admins or the developers where I work, but at least they
know where the logs are located

For the time being - and to give a hint - try using CGI::Carp (just
not in a production environment).

HTH and have a nice day

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
People usually get what's coming to them ... unless it's been
<mailed.

 

[Jay Tilton]

(e-mail address removed) (stew dean) wrote:

: The code it's self, although clunky no doubt compared to the abilities
: of many, works fine.

Then the Perl problem has been solved. Yay team!

: I'm thinking it's a set up issue with IIS.

You are probably right.

Since Perl is not IIS, an IIS-oriented newsgroup would be a more
appropriate place to seek help than a Perl newsgroup. The readers there
will at least be able to guide you to the location of the server's error
log.

Right now, the only thing known about the error is that it exists. That
is not enough information to begin diagnosis.

 

[stew dean]

(e-mail address removed) (stew dean) wrote in


The manual would tell you where to find the error logs so you can find
out what is wrong, and maybe give us a clue. That is not too much to ask.

That's my problem - the script is producing no errors as in the script
if fine, it runs without producing an error, that's why I think it's a
server related problem.

So, you cannot be bothered to check the error logs, and tell us what is
in there, but somehow we are supposed to divine what is going on ...
Interesting attitude.

I don't even know if there is an error log.

In the time you took to type up all these replies as to why you won't
check the error logs, you could have checked the error logs, and posted
some information that could have been helpful in figuring out the
problem.

So you know where the error log is then? Look I know you want to help
but you're not helping me.

I'm now going to try and find an error log that may or may not exist
(I have already spent an hour trying to find if one exists).

Stew Dean

 

[stew dean]

Perhaps the server is not configured to run scripts? Or, if you know
that the scripts are running, the page won't display, you must have a
problem with formatting (maybe you're not sending the "text/html"
prologue?).

In that case, try shift-clicking the link that launches the scripts,
so you can save the output to a file, then peruse the file. Name it
with a .html extension and try to load it directly.

Tried this and it never gets as far as giving me a file. The output
text has the full HTML headers and definition and I know it works when
processing a small XML file so this is all in order.

The server already runs many scripts with no problems so the perl is
set up and working happily - except in this case.

Thanks for what is probably the only helpful responce so far.

Stew Dean

 

[stew dean]

On 22 Oct 2003 04:27:54 -0700

<snip>

What happened when you ran the script at the command line?

I've never run a perl script at the command line.

There is
_little_ difference between running the script on the command line and
running it through the web server - especially if you use the CGI
module (hint - '-debug').

Where is the code you speak of? You have yet to post any offending
code.

There is no offending code. I'm not posting up my script as the script
works fine. It takes an XML file and spits out other files (html) and
one HTML page which tells me the script has run and gives me more
options (like adding details to selected pages).

The documentation for _Perl_ (specifically, perlfaq9) gives a tip or
two on debugging a buggy Perl CGI script.

The perl script is not buggy - it's running fine. It generates all the
files but for some reason is not producing my final HTML page.

And yes, I was insulting to you. Sorry for the transgression. By the
same token, if you run a web server, you should at least know where
the logs are located

Which logs? I use the events log, I run stats on the access logs. Now
what I don't appear to be able to find is the perl error log if there
is one.

For the time being - and to give a hint - try using CGI::Carp (just
not in a production environment).

Well that's enigmatic. I suspect that it's also not the answer I seek
but I will check it out.

Stew Dean

 

[Alan J. Flavell]

Thanks for what is probably the only helpful responce so far.

I think that's reached the plonk threshold now. Bye.

 

[Jürgen Exner]

The perl script is not buggy - it's running fine.

Then what is your problem? Apparently it has nothing to do with Perl or has
it?

jue

 

[James Willmore]

I've never run a perl script at the command line.

Why not?

There is no offending code. I'm not posting up my script as the script
works fine. It takes an XML file and spits out other files (html) and
one HTML page which tells me the script has run and gives me more
options (like adding details to selected pages).


The perl script is not buggy - it's running fine. It generates all the
files but for some reason is not producing my final HTML page.

Hum ... are you outputing the correct HTTP header? Maybe there _is_
something wrong with the script? A typo, maybe? Running the script
_at the command line_ will produce messages that _may_ not be seen as
errors, but as warnings that the web server is just dismissing. You
can also see what the script is sending out to the browser. What ever
you see at the command line is what _should_ be going to the browser.

Which logs? I use the events log, I run stats on the access logs. Now
what I don't appear to be able to find is the perl error log if there
is one.

There are _no_ Perl error logs. The error logs I was refering to were
the _server_ error logs. However, you can issue events to the
Window's Event Log from the script using the Win32::EventLog module.
By inserting some logging code into your script, you can see each time
the code to produce HTML is hit. You can then see what, if anything,
broke.

Well that's enigmatic. I suspect that it's also not the answer I seek
but I will check it out.

Like I mentioned before, maybe the code _is_ broke somewhere.
CGI::Carp can report the errors to the browser (since you seem to not
want to run the script at the command line). If something is broke,
the error will appear.

HTH

Jim
(jwillmore _at_ adelphia _dot_ net)

 

[stew dean]

Why not?

Because I've never had to. Why would I want to?

Hum ... are you outputing the correct HTTP header?
Yes.

Maybe there _is_
something wrong with the script? A typo, maybe? Running the script
_at the command line_ will produce messages that _may_ not be seen as
errors, but as warnings that the web server is just dismissing.

All errors that are generated by the script are displayed in the
output. It uses strict so all errors are picked up including variables
not declared. If it finds more than one it stops running and tells me.

Now there may be errors produced of a different kind but then this
would be new to me and I'm trying to find out what kind of errors they
may be. The code it's self is fine with no syntax errors.

If I run it from the command line it can't find the input file as the
file is relative to the web server. This is all about reading and
writing files afterall.

Like I mentioned before, maybe the code _is_ broke somewhere.
CGI::Carp can report the errors to the browser (since you seem to not
want to run the script at the command line). If something is broke,
the error will appear.

If something is broke it gives me the error by passing me the
headers. Will Carp give me any errors that I don't already receive
(given that I'm not adding debug messages into the script)?

Stew Dean

 

[stew dean]

Then what is your problem? Apparently it has nothing to do with Perl or has
it?

It's to do with the way perl is running on IIS - that is for some
reason it is running but the output is not reaching the browser.

It's also about finding out more about how Perl runs on windows.

Perl doesnt naturaly have an error log on windows from what I can see
and so far I have been relying on the errors given to me in the
headers returned -that is the usualy syntax and other errors that are
returned by using strict.

Now I'm exploring all the other suggestions but so far I've had not
joy.

Stew Dean

 

[stew dean]

I think that's reached the plonk threshold now. Bye.

Hang on - why does your name ring a bell? My god - it's the same Alan
Flavell I used to talk about HTML to way back in 1996. You where the
one who was saying HTML should not be used for layout. You even
suggested that all layout should be done in PDF at one point. Shame I
missed all your wining about Flash and what about style sheets?

Welcome to 2003 Alan.

Stew Dean

 

[Alan J. Flavell]

stew dean ([email protected]) wrote on MMMDCCV September
MCMXCIII in <URL:news:[email protected]>:

** Hang on - why does your name ring a bell? My god - it's the same Alan
** Flavell I used to talk about HTML to way back in 1996.

I was responding specifically to the current issues. I saw no reason
to rake-over past acrimony.

You where the
** one who was saying HTML should not be used for layout.

I'm one who's saying that the web has now finally caught up with the
recognition that HTML would better not be used for layout. The idea
of using stylesheets pre-dated RFC1866/HTML2.0, and it should have
been obvious to anyone who bothered to rub two brain cells together
that they were a good approach. It's taken too long to get there, but
it's finally happening, and I find that development rather positive.

But it really has nothing to do with how and where to look for
solutions to IIS problems.

*PLONK*

Well-plonked. :-}

(I talked about HTML way back in 1996 (and even before as well). I said
then, and I still say, that HTML should not be used for layout.

Indeed.

[f'ups prophylactically set...]

 

[stew dean]

(e-mail address removed) (stew dean) wrote:

: The code it's self, although clunky no doubt compared to the abilities
: of many, works fine.

Then the Perl problem has been solved. Yay team!

Be nice.

: I'm thinking it's a set up issue with IIS.

You are probably right.

Since Perl is not IIS, an IIS-oriented newsgroup would be a more
appropriate place to seek help than a Perl newsgroup.

My problem is running perl script on IIS. So although it is not
strictly to do with the perl code it is to do with the running of
perl.

I was hoping that someone here might run perl on IIS and know what my
problem is.

Right now, the only thing known about the error is that it exists. That
is not enough information to begin diagnosis.

There is no error from perl - that's my problem.

Stew Dean