MODPERL2 definition not defined
(from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75194) Hi, The technique presented in http://perl.apache.org/docs/2.0/devel/porting/porting.html#Requiring_a_specific_mod_perl_version_ doesn't work with mod_perl 1.99 in the server config files. The perl code sample in the document (Apache::exists_config_define(MODPERL2)) works, but IfDefine MODPERL2 doesn't. This is because IfDefine interpretation happens as the file is parsed; mod_perl is defining MODPERL2 in a pre_config hook, which happens after the file has been parsed, but before it has been processed. Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: [OT] use http-equiv to refresh the page
On Tue, 5 Nov 2002 at 22:52, Chris Shiflett opined: [snip] CS:The W3C's stance on refresh is the same for the header as well as the CS:meta tag: they did not originally intend for it to be used to specify a CS:*different* URL as a rudimentary method of redirection. They meant it to CS:be used to refresh the current resource only. However, this rogue CS:practice of redirection is quite common with both the header and the CS:meta tag and is very well supported by browsers. In fact, I am not aware CS:of any Web client that supports refresh but also limits the URL to the CS:current resource only. i was bitten by this assumption recently. case in point: i needed to develop a way to display several images as a slideshow using plain html files. i would glob the images, and in each html file i inserted a meta refresh that would load the next image in the series after a 7 second delay. since the html files were eventually going to be burned to a cd, i had to point to each new file as such: meta http-equiv=refresh content=7;file02.html because i cannot always assume to know the user's cd-rom drive designation. this worked fine in netscape and mozilla, but did not work at all in internet explorer versions previous to 5.5. in older versions of ie, it simply refreshed the current page after the 7 second delay, no matter what was put after the semicolon in the content attribute. so i had to include instructions for the users that if they used internet explorer, they must upgrade to at least version 5.5 for the slideshow to work. of course, i had tested the app on ie 5.5, so i didn't discover this myself until a user contact me and complained the slideshow wasn't working. and you'd be surprised how many old versions of ie are being used out there.
[ANNOUNCE] Apache::NavBarDD
The uploaded file Apache-NavBarDD-0.71.tar.gz has entered CPAN as file: $CPAN/authors/id/L/LO/LOURIDAS/Apache-NavBarDD-0.71.tar.gz size: 7324 bytes md5: ba426f5c30a19915572d28b888a6e57d Description --- The Apache::NavBarDD package provides a dynamic navigation bar along the lines of the NavBar module described in Lincoln Stein's and Doug MacEachern's Writing Apache Modules with Perl and C. It goes one step further in allowing double-decker (two-level) navigation bars, where the selection in the first level (the *master* bar) determines the contents of the second level (the *vassal* bar). See perldoc Apache::NavBarDD for module documentation and use. Cheers, Panos Louridas
RE: use http-equiv to refresh the page
I just wanted to mention that the meta tag as well as its http-equiv attribute are both official parts of the HTML standard and have been for quite some time. Yes and no. HTML 4.0 has a section on META and http-requiv. In it, it mentions that Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. and proceeds with an example. That sounds more advisory than part of the standard. But for the sake of argument, let's say it's part of the standard, and check what HTML 4.01 has to say. HTML 4.01 also has a section on META and http-requiv. However, the only reference to refresh is: Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should __not__ use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects. I'm guessing this is because http-equiv is designed to hold an HTTP header, but there is no such thing as an Refresh header in HTTP. So http-equiv=refresh is no longer standard. Of course, this is all theoretical. In practice, too many people are not easily swayed by a measily thing such as a standard. -- Eric L. Brine | ICQ: 4629314 [EMAIL PROTECTED] | MSN: [EMAIL PROTECTED] http://www.adaelis.com/ | AIM: ikegamiii
Re: use http-equiv to refresh the page
--- Perrin Harkins [EMAIL PROTECTED] wrote: I might be overzealous about this, but I dislike seeing HTTP-EQUIV meta tags used when actual HTTP headers are available to do the same thing. It's fine if there's a reason for it, but usually people do it because they don't realize they can just send a real header instead.. So what is the recommended way of doing wait pages ?? Sending a 302 wont definitely show the user anything other than all that text changing in the status bar. Mithun __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
[ANNOUNCE] mod_perl Developer's Cookbook now on Safari
hi all... we have received a few requests for an electronic version of the mod_perl Developer's Cookbook over the past few months, which we have thus far been unable to satisfy. yesterday I noticed that it has finally shown up on Safari: http://safari.informit.com/0672322404 so, for those who have wanted an electronic reference, this may do the trick. as always, all of the code from the book, as well as a nice search engine, can be found on our website http://www.modperlcookbook.org/ now back to your regularly scheduled hacking... --Geoff
RE: [OT] use http-equiv to refresh the page
Greetings. [...] [snip] CS:The W3C's stance on refresh is the same for the header as well as the CS:meta tag: they did not originally intend for it to be used to specify a CS:*different* URL as a rudimentary method of redirection. [...] i was bitten by this assumption recently. case in point: i needed to develop a way to display several images as a slideshow using plain html files. [..horror story clipped] But, in fact, redirects - either implicit or explicit - have many ways of biting the unwary (and curiously, or perhaps not, IE always a key role). Consider MS KB Article Q160013: If a CGI application returns a MIME Type that is unknown or not associated to Internet Explorer internally, Internet Explorer makes two POST requests to the server. What this means is that (for instance), sending a PDF file as the result of a POST request may cause the following sequence of events: 1) the file is downloaded 2) it is removed from the disk cache as the second POST request goes out 3) Acroread is launched and then says No such file. this bug is active on many, many versions of IE. It happens if you either send the file directly OR issue a redirect. The only workaround I could find was a meta-http-refresh. And then I found out that using '0' as a refresh time won't work on Mozilla (who tries to refressh the *current* page every 0 seconds and gets stuck in a loop- not nice). So what's a poor programmer to do, caught between standards and arguably buggy browsers? Cheers, alf P.S. Anybody knows of a better solution to Q160013, I'd like very much to hear about it...TIA.
sending ssl certificate according to virtual host
hi all, i'm actually working on a system where a user can create domains / subdomains throug a webinterface and doesn't have to interact with the httpd.conf. For this I use a unique virtualhost which intercept all client request no matter which vh is requested. After a handler treat the request and fetch the data where it should be fetch. Everyhing is working fine, but I would like to add SSL support on the system. I want to be able to send the SSL certificate and key files for the requested virtual host. Depending on the vh requested I set the SSLCertificateFile and SSLCertificateKeyFile which will point to the correct ssl files for the requested vh. Is there a way for doing this ? All input appreciated and I hope my explanatins are clear enough on what i want to do. Thanks, Mathieu
OO handlers
List,
Tired of having 10 modules all with near identical handler methods I
decided to put the handler method into a superclass and be done with
maintaining the same code 10 times. I first tried this a couple of weeks ago
and it failed to work, because at the time I couldn't find the reference to
OO style handler methods in my Eagle book. Since the mod_perl cookbook is
now available on safari I had a quick flick through and noticed a brief
mention on OO style handler methods along with the snippet of info I needed
i.e. sub handler ($$).
To cut a long story short my subclasses are now empty (for the moment) and
they inherit (or a least should be doing) from the main superclass.
Something like,
use Control/Super.pm
Control::Super::Sub::ISA = Control::Super;
I use a dispatch module with a basic handler to choose which module will
process a particular uri.
It now adds the module to be called like follows,
my $sub = join '::', 'Control', ucfirst $module, ucfirst $sub_stage;
$r-push_handlers('PerlHandler',$sub-handler);
The meaning of $module and $sub_stage is unimportant here.
And the Superclass handler looks like
sub handler ($$) {
my $self = shift;
my $r = Apache::Request-instance(shift);
# do stuff
}
Testing this with httpd -X causes a segfault every time I go to the URL. So
my question is, before I try to figure out why it segv's, is this kind of
thing allowed?, or is there some caveat which prevents handlers being
invoked if they come from a supeclass?
All help appreciated as usual,
Richard.
Re: sending ssl certificate according to virtual host
On Wed, Nov 06, 2002 at 11:52:13AM -0500, Vivek Khera wrote: What they should have done is what is done now with TLS in SMTP. You connect to the same port, but issue a STARTTLS command to switch over to secured mode. With this type of scheme, the header info with the desired host could be in the initial request, so then you could pick the right certificates to use. Alas, the HTTP protocol doesn't work this way as far as I can tell. An untested patch to support this in Apache 2 was sent to the devhttpd list by Ryan Bloom a few weeks back. Getting support for STARTTLS into Apache is only the first step - so far no clients support it yet. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: OO handlers
I should add that this segv only happens when using push_handlers like
below. If I put Control::Super::Sub-handler inside a Location tag in
httpd.conf then it is fine.
Ric
- Original Message -
From: Richard Clarke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 06, 2002 3:55 PM
Subject: OO handlers
List,
Tired of having 10 modules all with near identical handler methods I
decided to put the handler method into a superclass and be done with
maintaining the same code 10 times. I first tried this a couple of weeks
ago
and it failed to work, because at the time I couldn't find the reference
to
OO style handler methods in my Eagle book. Since the mod_perl cookbook is
now available on safari I had a quick flick through and noticed a brief
mention on OO style handler methods along with the snippet of info I
needed
i.e. sub handler ($$).
To cut a long story short my subclasses are now empty (for the moment) and
they inherit (or a least should be doing) from the main superclass.
Something like,
use Control/Super.pm
@Control::Super::Sub::ISA = Control::Super;
I use a dispatch module with a basic handler to choose which module will
process a particular uri.
It now adds the module to be called like follows,
my $sub = join '::', 'Control', ucfirst $module, ucfirst $sub_stage;
$r-push_handlers('PerlHandler',$sub-handler);
The meaning of $module and $sub_stage is unimportant here.
And the Superclass handler looks like
sub handler ($$) {
my $self = shift;
my $r = Apache::Request-instance(shift);
# do stuff
}
Testing this with httpd -X causes a segfault every time I go to the URL.
So
my question is, before I try to figure out why it segv's, is this kind of
thing allowed?, or is there some caveat which prevents handlers being
invoked if they come from a supeclass?
All help appreciated as usual,
Richard.
Re: OO handlers
Geoffrey Young wrote:
keep in mind that neither book mentions the use of subroutine
attributes, which is allowed in 1.3 but the only way in 2.0
sub handler : method {
...
}
I am 99% sure that Attribute handlers wont work in 1.3 because
Attribute::Handlers use CHECK{} blocks to set up the handlers. CHECK
blocks do not work in mod_perl under Apache 1.3 (search the list
archives for the reason). So because CHECK blocks never execute in
mod_perl under Apache 1.3 attribute handlers wont work. I tried to get
them work in under Apache 1.3 a few months ago, and gave up because of
the CHECK restrictions.
Mike
Re: sending ssl certificate according to virtual host
Mathieu Jondet [EMAIL PROTECTED] wrote: hi all, i'm actually working on a system where a user can create domains / subdomains throug a webinterface and doesn't have to interact with the httpd.conf. For this I use a unique virtualhost which intercept all client request no matter which vh is requested. After a handler treat the request and fetch the data where it should be fetch. Everyhing is working fine, but I would like to add SSL support on the system. I want to be able to send the SSL certificate and key files for the requested virtual host. Depending on the vh requested I set the SSLCertificateFile and SSLCertificateKeyFile which will point to the correct ssl files for the requested vh. Is there a way for doing this ? All input appreciated and I hope my explanatins are clear enough on what i want to do. HTTP rides on top of SSL/TLS. The SSL connection is established and certificates exchanged before any HTTP request is sent. The SSL certificate must be configured on a per-IP-address basis. You might want to look into a certificate for a wildcarded domain (e.g., *.mydomain.com) and have that handle all the subdomains. I think that's possible, but I'm not positive. We use fully qualified domain names ourselves. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: OO handlers
Michael Schout wrote:
Geoffrey Young wrote:
keep in mind that neither book mentions the use of subroutine
attributes, which is allowed in 1.3 but the only way in 2.0
sub handler : method {
...
}
I am 99% sure that Attribute handlers wont work in 1.3 because
Attribute::Handlers use CHECK{} blocks to set up the handlers. CHECK
blocks do not work in mod_perl under Apache 1.3 (search the list
archives for the reason). So because CHECK blocks never execute in
mod_perl under Apache 1.3 attribute handlers wont work. I tried to get
them work in under Apache 1.3 a few months ago, and gave up because of
the CHECK restrictions.
interesting. the last time I tried was with bleedperl before 5.8 was
released - I know it worked then because I was writing a patch for
mod_perl core based on it. this thread has most of the dialogue:
http://marc.theaimsgroup.com/?t=99789776100010w=2r=1
and below is the test I was using at the time. when trying it now
with my dev environment (Apache/1.3.28-dev (Unix) mod_perl/1.27_01-dev
Perl/v5.9.0) it works as I'd expect - the first two calls below are
broken, but the last two report back
self: My::MethodTest, r: Apache=SCALAR(0x838e850)
anyway, maybe we have different assumptions, but it seems to be
working as I would expect with the current versions.
--Geoff
package My::MethodTest;
# remember to PerlModule My::MethodTest
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r-push_handlers($r-current_callback = \foo);
$r-push_handlers($r-current_callback = \bar);
$r-push_handlers($r-current_callback = 'My::MethodTest-foo');
$r-push_handlers($r-current_callback = 'My::MethodTest-bar');
return OK;
}
sub foo : method {
my $self = shift;
my $r = shift;
print STDERR My::Method::foo\n;
print STDERR self: $self, r: $r\n;
return OK;
}
sub bar ($$) {
my $self = shift;
my $r = shift;
print STDERR My::Method::bar\n;
print STDERR self: $self, r: $r\n;
return OK;
}
1;
Re: OO handlers
Now I feel stupid. $sub-handler was supposed to be $sub-handler.
That's what you get for being impatient.
Ric
- Original Message -
From: Richard Clarke [EMAIL PROTECTED]
To: Richard Clarke [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, November 06, 2002 4:08 PM
Subject: Re: OO handlers
I should add that this segv only happens when using push_handlers like
below. If I put Control::Super::Sub-handler inside a Location tag in
httpd.conf then it is fine.
Ric
- Original Message -
From: Richard Clarke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 06, 2002 3:55 PM
Subject: OO handlers
List,
Tired of having 10 modules all with near identical handler methods I
decided to put the handler method into a superclass and be done with
maintaining the same code 10 times. I first tried this a couple of weeks
ago
and it failed to work, because at the time I couldn't find the reference
to
OO style handler methods in my Eagle book. Since the mod_perl cookbook
is
now available on safari I had a quick flick through and noticed a brief
mention on OO style handler methods along with the snippet of info I
needed
i.e. sub handler ($$).
To cut a long story short my subclasses are now empty (for the moment)
and
they inherit (or a least should be doing) from the main superclass.
Something like,
use Control/Super.pm
@Control::Super::Sub::ISA = Control::Super;
I use a dispatch module with a basic handler to choose which module
will
process a particular uri.
It now adds the module to be called like follows,
my $sub = join '::', 'Control', ucfirst $module, ucfirst $sub_stage;
$r-push_handlers('PerlHandler',$sub-handler);
The meaning of $module and $sub_stage is unimportant here.
And the Superclass handler looks like
sub handler ($$) {
my $self = shift;
my $r = Apache::Request-instance(shift);
# do stuff
}
Testing this with httpd -X causes a segfault every time I go to the URL.
So
my question is, before I try to figure out why it segv's, is this kind
of
thing allowed?, or is there some caveat which prevents handlers being
invoked if they come from a supeclass?
All help appreciated as usual,
Richard.
Re: OO handlers
Richard Clarke [EMAIL PROTECTED] wrote:
Now I feel stupid. $sub-handler was supposed to be $sub-handler.
That's what you get for being impatient.
or perhaps `sub { $sub - handler(@_) }' -- if quoting works,
great, but I would fear that $sub-handler would stringify before
push_handlers got called.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
RE: use http-equiv to refresh the page
I just wanted to mention that the meta tag as well as its http-equiv attribute are both official parts of the HTML standard and have been for quite some time. Yes and no. Well, I disagree with the no. I will explain it again below. HTML 4.0 has a section on META and http-requiv. In it, it mentions that \Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI.\ and proceeds with an example. That sounds more advisory than part of the standard. But for the sake of argument, let\'s say it\'s part of the standard, and check what HTML 4.01 has to say. HTML 4.01 also has a section on META and http-requiv. However, the only reference to \refresh\ is: \Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should __not__ use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects.\ I\'m guessing this is because http-equiv is designed to hold an HTTP header, but there is no such thing as an \Refresh\ header in HTTP. No, there is an HTTP header called Refresh, and it is standard. The meta tag and the http-equiv attribute of the meta tag are also standard. However, some people seem to be confusing HTTP and HTML here for some reason. Refresh is an HTTP standard, while the meta tag is HTML. The http-equiv attribute of the meta tag allows some HTTP headers to be specified in the HTML. While this feature offers little to mod_perl developers who can manipulate the headers themselves anyway, it was historically very helpful to developers for providing accurate HTTP headers such as Expires when they could not otherwise do this. The reason for that warning in the HTML specification is due to what the W3C likely considers a rampant abuse of the Refresh header which was not intended for redirection but only for refreshing the current resource. They are not warning against Refresh alone but rather what they consider a misuse of Refresh. The key phrase is, \with the option of replacing it by a different URI.\ This is what is frowned upon, not the meta HTML tag nor the Refresh HTTP header. So http-equiv=\refresh\ is no longer standard. Of course, this is all theoretical. In practice, too many people are not easily swayed by a measily thing such as a standard. Right, and this was my second point in an earlier message. Support for this rogue feature is pretty widespread, though it should not be completely trusted. As one of the other posters pointed out, there are Web clients that do not support the use of a meta tag for redirection, but many (possibly most) do. It is quite common to see the use of a meta tag for redirection accompanied by instructions on the screen and a link for users that are not automatically redirected. By accomodating the users who are not automatically redirected, you can eliminate the possibility of a dead-end. Of course, I hope that mod_perl developers always choose manipulating the real HTTP headers over the use of the http-equiv attribute of the meta tag. Also, it seems possible that there might be much wider support for redirection with the real Refresh HTTP header than for the meta tag equivalent. I know of at least one attempt to test and document support for this specific use: http://www.hixie.ch/tests/evil/mixed/refresh1.http.html Perhaps the results of this test can help a developer determine whether this misuse of the Refresh header is appropriate for a certain situation. Chris
Re: OO handlers
Richard Clarke wrote:
List,
Tired of having 10 modules all with near identical handler methods I
decided to put the handler method into a superclass and be done with
maintaining the same code 10 times. I first tried this a couple of weeks ago
and it failed to work, because at the time I couldn't find the reference to
OO style handler methods in my Eagle book. Since the mod_perl cookbook is
now available on safari I had a quick flick through and noticed a brief
mention on OO style handler methods along with the snippet of info I needed
i.e. sub handler ($$).
as you've probably discovered, you're using a feature called 'method
handlers' and you should be able to find examples in the eagle book as
well.
keep in mind that neither book mentions the use of subroutine
attributes, which is allowed in 1.3 but the only way in 2.0
sub handler : method {
...
}
[snip]
I use a dispatch module with a basic handler to choose which module will
process a particular uri.
It now adds the module to be called like follows,
my $sub = join '::', 'Control', ucfirst $module, ucfirst $sub_stage;
$r-push_handlers('PerlHandler',$sub-handler);
even though you figured it out already, you might want to check out
how Apache::Dispatch does it - there are some security concerns that
have been addressed there that you might be interested in.
BTW, for anyone going to ApacheCon this month, I'll be giving a 2 hour
presentation on OO mod_perl techniques.
http://www.apachecon.com/html/session-popup.html?id=669
the actual contents differ a bit from the outline - if you were at
YAPC::NA it's pretty much the same as the middle part of that talk.
basically, the first 25% is about standard OO like sub handler ($$),
while the rest shows how to do augment core mod_perl via some really
cool subclassing.
cya there
--Geoff
[OT] Re: sending ssl certificate according to virtual host
- Original Message - From: Vivek Khera [EMAIL PROTECTED] Newsgroups: ml.apache.modperl To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 6:52 PM Subject: Re: sending ssl certificate according to virtual host MJ == Mathieu Jondet [EMAIL PROTECTED] writes: MJ Depending on the vh requested I set the SSLCertificateFile and MJ SSLCertificateKeyFile which will point to the correct ssl files for the MJ requested vh. What they should have done is what is done now with TLS in SMTP. You connect to the same port, but issue a STARTTLS command to switch over to secured mode. With this type of scheme, the header info with the desired host could be in the initial request, so then you could pick the right certificates to use. Alas, the HTTP protocol doesn't work this way as far as I can tell. I dunno... What if you want to send a cookie in secured mode? That's part of the headers, and of equal priority as the Hostname: header used to determine the correct VirtualHost to use... I'm sure that SSL could be fit much nicer over HTTP/1.1, but it would probably rip apart alot of the solid standards involved - such as creating priorities inside the headers, or the option to take multiple commands... Origianlly, when writing this email, I was going to suggest a CONNECT / STARTTLS scheme which would work in Keep-Alive mode until the server clsoed the connection... But then I found an existing RFC which describes it - so the question (probably a stupid one which I don't realize is stupid only because I just now stumbled accross the RFC and still don'ty properly understand what's involved) is: why is it not implemented? Anyway, the RFC in question is 2817 (http://www.ietf.org/rfc//rfc2817.txt) Issac
Re: sending ssl certificate according to virtual host
MJ == Mathieu Jondet [EMAIL PROTECTED] writes: MJ Depending on the vh requested I set the SSLCertificateFile and MJ SSLCertificateKeyFile which will point to the correct ssl files for the MJ requested vh. You can't do this with name-based vhosts. To present the proper SSL certificate, you have to do it at the connection time (before any data, including the desired host name is sent to you), and you can only do that with unique IP addresses or unique port numbers per vhost. Yes, this sucks. The people who invented SSL were not very forward thinking. What they should have done is what is done now with TLS in SMTP. You connect to the same port, but issue a STARTTLS command to switch over to secured mode. With this type of scheme, the header info with the desired host could be in the initial request, so then you could pick the right certificates to use. Alas, the HTTP protocol doesn't work this way as far as I can tell. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Can't locate object method new via package Apache::Request (via Mason)...
Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
Getting the server to parse files after the handler has done itswork...
Hi All, I have the following scenario: * A Perl Handler i have written does a bit of work and outputs HTML * The HTML it outputs contains HTML like: !--#include virtual=/includes/misc/topnav.html -- I need this to be further parsed by Apache's Server Parsing Process. Does anyone know what i have to do for the above to work. simran. ps: Its not really practical to get the handler to include the topnav.html file and include it as it contains further includes which have further includes etc...
Re: Can't locate object method new via package Apache::Request (via Mason)...
Seems somewhat similar to a bug I've reported 10 months ago.
You might want to try to run the minimal testcase enclosed in the
forwarded mail.
Phil.
---BeginMessage---
I've found that mod_perl can get confused when dealing with method
calls during a redirect_internal phase:
1. page /1 uses method calls, and works when accessed as /1
2. an other page /R uses internal_redirect to go to /1, and mod_perl
fails with an undefined subroutine error.
This has been seen on:
apache 1.3.9-14, perl 5.004.05-1.1, and mod_perl 1.25-3 (Debian potato)
and on:
apache 1.3.22-2.1, perl 5.6.1-6, and mod_perl 1.26-1 (Debian woody/testing)
How to reproduce:
Use this startup.pl file:
==
# Common
package Common;
use Apache::Constants qw(:common);
sub handler($$)
{
my $self = shift;
my $req = shift;
$req-content_type('text/plain');
$req-send_http_header();
$req-print($self-doit());
return OK;
}
sub doit
{
return COMMON;
}
# Common::Impl1
package Common::Impl1;
ISA=qw(Common);
sub doit
{
return IMPL1\n;
}
# Common::Impl2;
package Common::Impl2;
ISA=qw(Common);
sub doit
{
return IMPL2\n;
}
# Redir
package Redir;
use Apache::Constants qw(:common);
sub handler
{
my $req = shift;
$req-internal_redirect(/1);
return OK;
}
1;
==
PerlRequire the above, and use the following apache configuration:
==
Location /0
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common
/Location
Location /1
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl1
/Location
Location /2
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl2
/Location
Location /R
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Redir
/Location
PerlRequire startup.pl
==
Then, directing a web browser to /0 prints COMMON, to /1 prints IMPL1,
to /2 prints IMPL2, as expectected.
Similarly, when pointing to /R (which redirects internally to /1),
IMPL1 should appear.
However, I get a 500 Internal server error and this in the logs:
[error] Undefined subroutine Common::Impl1::handler called at
startup.pl line 49.
I've tried to debug the problem, and the problem lies inside
perl_handler_ismethod() in src/modules/perl/mod_perl.c: it returns
different values when called from inside the internal_redirect than
called without internal_redirect.
Inside perl_handler_ismethod():
if(!sub) return 0;
sv = newSVpv(sub,0);
if(!(cv = sv_2cv(sv, stash, gv, FALSE))) {
GV *gvp = gv_fetchmethod(pclass, sub);
if (gvp) cv = GvCV(gvp);
sv_2cv() returns different values when called from inside an
internal_redirect than called without
internal_redirect. Unfortunately, I could not grok sv_2cv(). It's not
even documented in the perl docs.
Phil.
---End Message---
Re: use http-equiv to refresh the page
On the use of META REFRESH tags, Chris wrote: It is also the only option for the pause, then redirect behavior the original poster desired that I can think of. I also seem to recall reading in the HTTP spec (and in Lincoln's CGI.pm code) that the use of a Redirect header in response to a POST request was specifically verboten. But, as was noted, everyone does it anyway and it works. Weiqi really needs to look at his apache logs, try running his CGI from the command line to see the exact output the browser sees. Of course, he'll have to manually perform the redirect :=) Use the lwp-request tools (GET and POST) to get live interaction with the webserver in question if running the CGI is not possible. Also, NPH is only implemented in the NS browsers, and was a way for a webserver to send multiple documents inline down to a browser, and was an ancient way to write status pages and such that automagically refreshed themselves. It was originally used as a primitive way to animate images. IE will display these pages as a single never-ending document separated by the headers. If you're running a long-running CGI and need the browser to keep the connection alive, you need to periodically (2 minutes for IE, but is browser specific) send something to the browser - like a waiting page that dribbles out whitespace until the document is ready. There are more complicated ways to do this as well, and that technique is dated to modern web users. In any case, I don't think the issue is a mod_perl one, but rather a CGI.pm one. BTW, Weiqi - there is a stlouis.pm perlmongers list. Mike808/ - http://www.valuenet.net
Re: use http-equiv to refresh the page
[EMAIL PROTECTED] wrote: Also, NPH is only implemented in the NS browsers, and was a way for a webserver to send multiple documents inline down to a browser, and was an ancient way to write status pages and such that automagically refreshed themselves. No, that's server push you're thinking of. NPH (non-parsed header) scripts are CGI scripts that talk directly to the client without the server parsing headers and adding others (like the one that says it's Apache). Normally, mod_cgi adds the response line and certain other headers, so it parses your output. This is the same as using mod_perl with the PerlSendHeader option on. NPH script behave like mod_perl with PerlSendHeader off. - Perrin
Re: Getting the server to parse files after the handler has done its work...
Hello Simran, At 00:50 07.11.2002, simran wrote: I have the following scenario: * A Perl Handler i have written does a bit of work and outputs HTML * The HTML it outputs contains HTML like: !--#include virtual=/includes/misc/topnav.html -- I need this to be further parsed by Apache's Server Parsing Process. Does anyone know what i have to do for the above to work. You want Apache::OutputChain or Apache::Filter together with an SSI module. See http://perl.apache.org/docs/1.0/guide/modules.html#Apache__OutputChainChain_Stacked_Perl_Handlers and the paragraph below that for Apache::Filter. -- Per Einar Ellefsen [EMAIL PROTECTED]
mod_perl test report
mod_perl VERSION: 1.25 Apache version: 1.3.26 Apache MMN: 19990320 make[1]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Apache' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Apache' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Connection' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Connection' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Constants' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Constants' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/File' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/File' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Leak' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Leak' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Log' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Log' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/ModuleConfig' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/ModuleConfig' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/PerlRunXS' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/PerlRunXS' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Server' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Server' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Symbol' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Symbol' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Table' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Table' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/URI' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/URI' make[2]: Entering directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Util' make[2]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25/Util' cp t/conf/mod_perl_srm.conf t/conf/srm.conf /Andrews/tcbsrc/apache/apache-ssl-1.3.26.1+1.48/build-tree/apache_1.3.26/src//httpsd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok make[1]: Leaving directory `/Andrews/tcbsrc/apache/mod_perl/backport/libapache-mod-perl-1.25' Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.15pre14, archname=i386-linux uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 ', gccversion=2.95.2 2313 (Debian GNU/Linux) cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
