Help configuring Perl with Apache 2

Cyde Weys · Cyde Weys

This is more of an Apache question than a Perl question, but I'll go
for it here. I installed RedHat 9 (including Apache 2 and Perl) from
CD. Now, I'm trying to configure the webserver to execute perl scripts.
I have set the "Options ExecCGI" as well as the "AddHandler cgi-script
..pl" ... but when I try to load up index.pl, I get a "Forbidden access"
error message. I have chmod a+x the index.pl file. When I take out the
line "AddHandler cgi-script .pl", opening up index.pl just shows you the
contents of the .pl file. I don't see why I'm getting "forbidden" error
messages ... I do have the permissions set up to allow it to run. Also,
I've verified that the Perl file runs correctly from the www directory
with "./index.pl" ... any help would be greatly appreciated. Thanks.

BTW, as of now, index.pl is this:

#!/usr/bin/perl
print("Test\n");

John Bokma · John Bokma

Cyde Weys wrote:

> This is more of an Apache question than a Perl question, but I'll go
> for it here. I installed RedHat 9 (including Apache 2 and Perl) from
> CD. Now, I'm trying to configure the webserver to execute perl scripts.
> I have set the "Options ExecCGI" as well as the "AddHandler cgi-script
> .pl" ... but when I try to load up index.pl, I get a "Forbidden access"
> error message. I have chmod a+x the index.pl file. When I take out the
> line "AddHandler cgi-script .pl", opening up index.pl just shows you the
> contents of the .pl file. I don't see why I'm getting "forbidden" error
> messages ... I do have the permissions set up to allow it to run. Also,
> I've verified that the Perl file runs correctly from the www directory
> with "./index.pl" ... any help would be greatly appreciated. Thanks.

check error_log

> BTW, as of now, index.pl is this:
>
> #!/usr/bin/perl
> print("Test\n");

which is *wrong*

Check out CGI.pm and read about "headers". Don't write CGI perl scripts
with your own homebrew CGI.

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Cyde Weys · Cyde Weys

John Bokma wrote:

> Check out CGI.pm and read about "headers". Don't write CGI perl scripts
> with your own homebrew CGI.

Okay, I know about CGI.pm ... I've used it before ... but are you saying
that becuase I'm not using correct Perl CGI I'm getting forbidden error
messages?

John Bokma · John Bokma

Cyde Weys wrote:

> John Bokma wrote:
>

>> Check out CGI.pm and read about "headers". Don't write CGI perl
>> scripts with your own homebrew CGI.

>
>
> Okay, I know about CGI.pm ... I've used it before ... but are you saying
> that becuase I'm not using correct Perl CGI I'm getting forbidden error
> messages?

If you fix that problem you get a 505 server error because you don't
send a header (so I prevented maybe a future error :-)

Check the error_log

locate error_log

or

find / -name error_log -print

or, if you know the location of the conf dir, the logs dir is often in
the same dir as conf.

During development it is always a good idea to have an console which does:

tail -f error_log

Another tip: use the -w and -T switch *both* and use strict;

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Nico Coetzee · Nico Coetzee

On Sun, 07 Sep 2003 14:38:13 -0400, Cyde Weys wrote:

> John Bokma wrote:
>

>> Check out CGI.pm and read about "headers". Don't write CGI perl scripts
>> with your own homebrew CGI.

>
> Okay, I know about CGI.pm ... I've used it before ... but are you saying
> that becuase I'm not using correct Perl CGI I'm getting forbidden error
> messages?

You should at least send the content type header:

print "Content-type: text/html\n\n";
print "<html>....</html>";

Note the double '\n' after the header

Cheers

--
Nico Coetzee

[url]http://www.itfirms.co.za/[/url]
[url]http://za.pm.org/[/url]
[url]http://forums.databasejournal.com/[/url]

To the systems programmer, users and applications serve only to provide a
test load.

John Bokma · John Bokma

Nico Coetzee wrote:

> On Sun, 07 Sep 2003 14:38:13 -0400, Cyde Weys wrote:
>
>

>>John Bokma wrote:
>>
>>

>>>Check out CGI.pm and read about "headers". Don't write CGI perl scripts
>>>with your own homebrew CGI.

>>
>>Okay, I know about CGI.pm ... I've used it before ... but are you saying
>>that becuase I'm not using correct Perl CGI I'm getting forbidden error
>>messages?

>
>
> You should at least send the content type header:
>
> print "Content-type: text/html\n\n";
> print "<html>....</html>";
>
> Note the double '\n' after the header

And that's why I advise using CGI.pm. Then you don't have to think about
that.

use CGI;

my $cgi = new CGI;

print $cgi->header,
$cgi->start_html(...)
:
$cgi->end_html;

Notice that I prefer using $cgi instead of $q or $query. Using $q(uery)
is confusing since the object is not used for query only, especially not
in this example.

Also I recommend using the HTML generating functions instead of doing
your own <html>... stuff. Only yesterday I had to fix two occurences of
"<tr>" to the correct "</tr>" in my code :-(

Always validate your HTML output.

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Tad McClellan · Tad McClellan

Cyde Weys <cyde@umd.edu> wrote:

> This is more of an Apache question than a Perl question, but I'll go
> for it here.

*plonk*

--
Tad McClellan SGML consulting
[email]tadmc@augustmail.com[/email] Perl programming
Fort Worth, Texas

Gunnar Hjalmarsson · Gunnar Hjalmarsson

Vlad Tepes wrote:

> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:

>> Defaulting to a more recent W3C recommendation does not appear
>> odd or bad to me. Even if I'm not a member of the CGI.pm fan
>> club, this seems not to be a proper base for criticizing the
>> module.

>
> Is it not so that one of the most used browsers have trouble with
> XHTML? If this is the case, using XHTML as default could be a bad
> thing.

I suppose it depends on the nature of the trouble. Btw, which browser
is it?

--
Gunnar Hjalmarsson
Email: [url]http://www.gunnar.cc/cgi-bin/contact.pl[/url]

Vlad Tepes · Vlad Tepes

Cyde Weys <cyde@umd.edu> wrote:

> Vlad Tepes wrote:
>
> I should have phrased my question more carefully then. I didn't mean,
> "I know this belongs in another group but I'll post it here just to
> screw with you guys and lower the s/n ratio."

Good.

> I meant, "Perhaps this is more applicable to an Apache newsgroup, but
> since the question deals with how to configure Apache to work WITH
> PERL, I think I might get more knowledgable responses here."

I'd like to inform you about these groups:

comp.infosystems.[url]www.servers[/url]
comp.infosystems.[url]www.authoring.cgi[/url]

Asking for help in the proper group is likely to give you the best
resonses.

Hope this helps,
--
Vlad

Purl Gurl · Purl Gurl

John Bokma wrote:

> Purl Gurl wrote:

> > John Bokma wrote:

> > >Purl Gurl wrote:

> > You must be Robert Duvall.

> Why? Who? What?

Your email address.

THX1138 starring a very young Robert Duvall.
This is a famous science fiction story and movie.

Purl Gurl

John Bokma · John Bokma

Gunnar Hjalmarsson wrote:

> John Bokma wrote:
>

>> I use XHTML currently on parts of my site, but am going to change
>> it (back) to HTML 4.01 strict.
>>
>> If CGI.pm defaults to XHTML I consider this a bit odd. Maybe even
>> bad.

>
>
> Why? at [url]http://www.w3.org/MarkUp/[/url] I read: "XHTML is the successor of
> HTML, and a series of specifications has been developed for XHTML."

Well, since XHTML assumes that browsers accept *invalid* HTML like:

<br />

for one. Also when you output XHTML you should send the proper headers.
I don't know if CGI.pm does this (i.e. text/html for a non-XML browser
but application/xml-something for an XML browser, have to look that up).
Also some browsers choke on the XML prolog, see:

[url]http://www.webstandards.org/learn/reference/prolog_problems.html[/url]

> Defaulting to a more recent W3C recommendation does not appear odd or
> bad to me.

To me it does. It used to output HTML, now it switches to XHTML
"suddenly". This happens under the hood. Which is bad. It means that the
output of your CGI script changes when you update CGI.pm... (or worse,
when your hosting provider does...)

> Even if I'm not a member of the CGI.pm fan club, this seems
> not to be a proper base for criticizing the module.

See above. It means that an update of CGI.pm changes the output of CGI
scripts which is bad bad bad. Especially since CGI.pm belongs to the
core (IIRC). It means people have to update *all* their CGI scripts to
make it behave as it did in the past. Doesn't that strike you as
somewhat odd?

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

John Bokma · John Bokma

Gunnar Hjalmarsson wrote:

> Vlad Tepes wrote:
>

>> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>>

>>> Defaulting to a more recent W3C recommendation does not appear
>>> odd or bad to me. Even if I'm not a member of the CGI.pm fan
>>> club, this seems not to be a proper base for criticizing the
>>> module.

>>
>>
>> Is it not so that one of the most used browsers have trouble with
>> XHTML? If this is the case, using XHTML as default could be a bad
>> thing.

>
>
> I suppose it depends on the nature of the trouble. Btw, which browser
> is it?

see

[url]http://www.webstandards.org/learn/reference/prolog_problems.html[/url]
[url]http://hixie.ch/advocacy/xhtml[/url]

the latter was given me in a question regarding which one to choose:
XHTML 1.0 or HTML 4.01:

<http://groups.google.com/groups?th=b01676c5c4c075fd&seekm=3f2cba65.10491999 6%40news.cis.dfn.de>

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Gunnar Hjalmarsson · Gunnar Hjalmarsson

John Bokma wrote:

> Gunnar Hjalmarsson wrote:
>

>> John Bokma wrote:
>>

>>> I use XHTML currently on parts of my site, but am going to change
>>> it (back) to HTML 4.01 strict.
>>>
>>> If CGI.pm defaults to XHTML I consider this a bit odd. Maybe even
>>> bad.

>>
>>
>>
>> Why? at [url]http://www.w3.org/MarkUp/[/url] I read: "XHTML is the successor of
>> HTML, and a series of specifications has been developed for XHTML."

>
>
> Well, since XHTML assumes that browsers accept *invalid* HTML like:
>
> <br />
>
> for one. Also when you output XHTML you should send the proper headers.
> I don't know if CGI.pm does this (i.e. text/html for a non-XML browser
> but application/xml-something for an XML browser, have to look that up).
> Also some browsers choke on the XML prolog, see:
>
> [url]http://www.webstandards.org/learn/reference/prolog_problems.html[/url]
>

>> Defaulting to a more recent W3C recommendation does not appear odd or
>> bad to me.

>
>
> To me it does. It used to output HTML, now it switches to XHTML
> "suddenly". This happens under the hood. Which is bad. It means that the
> output of your CGI script changes when you update CGI.pm... (or worse,
> when your hosting provider does...)
>

>> Even if I'm not a member of the CGI.pm fan club, this seems
>> not to be a proper base for criticizing the module.

>
>
> See above. It means that an update of CGI.pm changes the output of CGI
> scripts which is bad bad bad. Especially since CGI.pm belongs to the
> core (IIRC). It means people have to update *all* their CGI scripts to
> make it behave as it did in the past. Doesn't that strike you as
> somewhat odd?
>
>

--
Gunnar Hjalmarsson
Email: [url]http://www.gunnar.cc/cgi-bin/contact.pl[/url]

Alan J. Flavell · Alan J. Flavell

On Sun, Sep 7, Cyde Weys inscribed on the eternal scroll:

> Vlad Tepes wrote:
>

> > Since you're now plonked by Tad and Abigail, you're not likely to get an
> > answer from them.

>
> Yeah, I figure as much. I'm not stupid. But sometimes people only say
> *plonk* just to show off or make a statement, but they never actually go
> through with their threat.

When you find yourself down a hole, it's wise to stop digging. If you
didn't know beforehand that Tad and Abigail have their respective
reputations on this group, it's not hard to find out.

> I should have phrased my question more carefully then. I didn't mean,
> "I know this belongs in another group but I'll post it here just to
> screw with you guys and lower the s/n ratio." I meant, "Perhaps this is
> more applicable to an Apache newsgroup, but since the question deals
> with how to configure Apache to work WITH PERL, I think I might get more
> knowledgable responses here."

The knowledgeable responses that you got seemed to show that you have
two evident problems: one of them belongs on the c.i.w.servers.*
hierarchy as it relates to Apache configuration, and the other belongs
on the c.i.w.authoring.cgi group as it relates specifically to the
CGI. At no point did you exhibit anything that was a Perl problem
(you clearly have the ability to write a syntactically correct print
statement in Perl, just that what you printed wasn't useful for its
purpose). I initially gave you the benefit of the doubt, where others
evidently felt you had already gone too far with the discourteous way
you expressed your question.

You might not have known that before, but you better believe it now,
if you're to stand any hope of convincing the hon. Usenauts of your
claim that you're 'not stupid'.

best regards

Vlad Tepes · Vlad Tepes

Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:

> Vlad Tepes wrote:

>> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:

>>> Defaulting to a more recent W3C recommendation does not appear
>>> odd or bad to me. Even if I'm not a member of the CGI.pm fan
>>> club, this seems not to be a proper base for criticizing the
>>> module.

>>
>> Is it not so that one of the most used browsers have trouble with
>> XHTML? If this is the case, using XHTML as default could be a bad
>> thing.

>
> I suppose it depends on the nature of the trouble. Btw, which browser
> is it?

Internet Explorer. Some of the problems are explained here:

[url]http://devedge.netscape.com/viewsource/2003/xhtml-style-script/[/url]

--
Vlad

John Bokma · John Bokma

Purl Gurl wrote:

> John Bokma wrote:
>
>

>>Purl Gurl wrote:
>>

>>>John Bokma wrote:
>>>
>>>>Purl Gurl wrote:

>
>

>>>You must be Robert Duvall.

>
>

>>Why? Who? What?

>
> Your email address.

It was something that popped into my head as "this is not a waste of an
valuable email address". I use it to check if harvesting bots do harvest
the reply-to header :-). So far only viruses per email. Probably via
people that contacted me on that address.

> THX1138 starring a very young Robert Duvall.
> This is a famous science fiction story and movie.

Thanks. I knew it was a SF thing, and even a movie.

I also know Robert Duvall is an actor but I didn't know the connection
(I rarely remember names of actors and actresses).

Thanks!

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Gunnar Hjalmarsson · Gunnar Hjalmarsson

[sorry for my previous post - pushed the Send button by mistake. :( ]

John Bokma wrote:

> Gunnar Hjalmarsson wrote:

>> Defaulting to a more recent W3C recommendation does not appear
>> odd or bad to me.

>
> To me it does. It used to output HTML, now it switches to XHTML
> "suddenly". This happens under the hood.

<snip>

> It means that an update of CGI.pm changes the output of CGI scripts
> which is bad bad bad. Especially since CGI.pm belongs to the core
> (IIRC). It means people have to update *all* their CGI scripts to
> make it behave as it did in the past. Doesn't that strike you as
> somewhat odd?

I see your point, but it rather strikes me as a natural consequence of
using a module in such a dynamic area as generating HTML. (Personally
I don't do that.)

What would the alternative be? Never change anything, even if 'the
outside world' changes?

--
Gunnar Hjalmarsson
Email: [url]http://www.gunnar.cc/cgi-bin/contact.pl[/url]

John Bokma · John Bokma

Gunnar Hjalmarsson wrote:

> [sorry for my previous post - pushed the Send button by mistake. :( ]

:-)

> John Bokma wrote:
>

>> Gunnar Hjalmarsson wrote:
>>

>>> Defaulting to a more recent W3C recommendation does not appear
>>> odd or bad to me.

>>
>>
>> To me it does. It used to output HTML, now it switches to XHTML
>> "suddenly". This happens under the hood.

>
>
> <snip>
>

>> It means that an update of CGI.pm changes the output of CGI scripts
>> which is bad bad bad. Especially since CGI.pm belongs to the core
>> (IIRC). It means people have to update *all* their CGI scripts to make
>> it behave as it did in the past. Doesn't that strike you as somewhat odd?

>
>
> I see your point, but it rather strikes me as a natural consequence of
> using a module in such a dynamic area as generating HTML. (Personally
> I don't do that.)
>
> What would the alternative be? Never change anything, even if 'the
> outside world' changes?

There are two possibilities:

[1] stick to HTML unless told otherwise
[2] adapt to what is hot

The problem is that [2] changes the output of scripts each time CGI.pm
has a new idea of what is "hot".

Since there are some problems related with XHTML I don't think switching
to XHTML is such a good idea at the moment, especially since HTML is
still supported and probably will be supported for the next several
years by most if not all browsers.

Basically it means when somewhere a hosting provider updates CGI.pm a
customer of mine can get unexpected output from his script which can
make browsers of his customers behave odd...

--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: [url]http://johnbokma.com/[/url] ICQ: 218175426
John web site hints: [url]http://johnbokma.com/websitedesign/[/url]

Gunnar Hjalmarsson · Gunnar Hjalmarsson

John Bokma wrote:

> Gunnar Hjalmarsson wrote:

>> I see your point, but it rather strikes me as a natural
>> consequence of using a module in such a dynamic area as
>> generating HTML. (Personally I don't do that.)
>>
>> What would the alternative be? Never change anything, even if
>> 'the outside world' changes?

>
> There are two possibilities:
>
> [1] stick to HTML unless told otherwise
> [2] adapt to what is hot
>
> The problem is that [2] changes the output of scripts each time
> CGI.pm has a new idea of what is "hot".
>
> Since there are some problems related with XHTML I don't think
> switching to XHTML is such a good idea at the moment, especially
> since HTML is still supported and probably will be supported for
> the next several years by most if not all browsers.

I can understand that you question the _timing_ for the change,
especially after having studied the documents you and Vlad pointed us
to. (Thanks for those links!)

> Basically it means when somewhere a hosting provider updates CGI.pm
> a customer of mine can get unexpected output from his script which
> can make browsers of his customers behave odd...

To me that appears as an unavoidable problem - sooner or later.
Possibility [1] would of course be an option for the time being.

--
Gunnar Hjalmarsson
Email: [url]http://www.gunnar.cc/cgi-bin/contact.pl[/url]

Alan J. Flavell · Alan J. Flavell

On Mon, Sep 8, John Bokma inscribed on the eternal scroll:

> There are two possibilities:
>
> [1] stick to HTML unless told otherwise
> [2] adapt to what is hot
>
> The problem is that [2] changes the output of scripts each time CGI.pm
> has a new idea of what is "hot".
>
> Since there are some problems related with XHTML I don't think switching
> to XHTML is such a good idea at the moment,

Neither do I, as it happens; but I'm not sure that was so evident at
the time the change was made to CGI.pm. L.S was clearly relying on
the so-called Appendix C compatibility - which I rate as a mistake,
but that's not to impute that there wasn't an honest intention behind
it.

> especially since HTML is still supported

Well, that rather depends on what you understand "HTML" to be. The
W3C's specifications are self-contraditory, as they on the one hand
define HTML to be an application of SGML, while on the other hand
outlawing things which SGML doesn't allow to be outlawed.

> and probably will be supported for the next several years by most if
> not all browsers.

It's pretty clear that the key features of XML (specifically:
declaring erroneous content to be unusable and quitting) will never be
"supported" by browsers. The merchants of tag-soup couldn't allow it.
So the choice is between HTML-flavoured tag soup, which was the
problem that XML was aimed to solve; or quasi-XHTML-flavoured tag
soup, which brings us the worst of both worlds.

But at the time that CGI.pm made the change, this might not have been
so evident ;-}

> Basically it means when somewhere a hosting provider updates CGI.pm a
> customer of mine can get unexpected output from his script

Well, I don't think that old versions of CGI would mind if you told
them not to generate XHTML. Then you'd be all set for an update.

In an ideal world, it might not have happened that way, but the CGI.pm
change to XHTML isn't exactly new - you appear to be fighting last
year's battles, to be fran^W honest.

all the best

Help configuring Perl with Apache 2

Thread Tools

Display

Help configuring Perl with Apache 2

Similar Questions and Discussions

Configuring Apache to accept DW/Contr templates

Apache htaccess and perl

Manually Configuring Apache to Run .CFM pages

Configuring Jpgraph on Windows 2000+Apache+PHP+MySql server

perl and/und apache

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: Help configuring Perl with Apache 2

Re: Help configuring Perl with Apache 2

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: Help configuring Perl with Apache 2

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: Help configuring Perl with Apache 2

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Re: HTML or XHTML in CGI [was: Help configuring Perl...]

Posting Permissions