Re: Using SSI with perl handlers?
On Mon, 2003-11-17 at 01:36, Christopher P. Lindsey wrote: >Basically, it all boils down to the fact that once an SSI directive >with #EXEC CGI is parsed, the document fails to parse any further >SSI directives *if the script to be executed has a perl-script >handler.* What happens if you use "#include virtual" instead? The "#exec cgi" directive has been deprecated in mod_include for years. The Apache::SSI module sets the content-type to "application/x-httpd-cgi" when you use exec cgi, and that might be causing a problem here, since what you are including are not actually CGI scripts. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
> What happens if you use "#include virtual" instead? The "#exec cgi" > directive has been deprecated in mod_include for years. The Apache::SSI > module sets the content-type to "application/x-httpd-cgi" when you use > exec cgi, and that might be causing a problem here, since what you are > including are not actually CGI scripts. Hi Perrin, I actually get the same results, but I appreciate the idea! Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH perl_reference.pod "Remedies for Inner Subroutines"
Stas Bekman <[EMAIL PROTECTED]> writes: > Brian McCauley wrote: > > > > Stas Bekman <[EMAIL PROTECTED]> writes: > >> > >>I think it would be more clear if all are declared at the top of the > >>file, > > > > Declaring variables at the top of the file is, IMNSHO, a bad > > programming habit that should be discouraged. > > Sorry I've missed the word "globals" while typing [...] > > You are talking about the locality rule, which I perfectly agree with > when it comes to scoped variables. > > However when it comes to globals I tend to disagree with you. [ snip - Stas correctly anticipates all my arguments in the debate ] > Agreed. I used to think I was the only person I knew who could loose a debate without letting the other guy get a word in. :-) > Both are now committed and will appear online within the next 6 hours. Phew! > Thanks a lot, Brian. Please keep those patches coming (and I promise > to be build less walls next time). Will do - but right now I have other fish to fry. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: transaction Apache::DBI
An interesting test would be to put a sleep(20) adter the delcaration of
the second database handle, then open a mysql shell and do a :
show processlist;
to see how many connections you have to your database server. My guess
is that you will see one. If thats the case, then whats happening is
probably the following: Because Apache::DBI uses the
DSN/username/password combination to uniquely identify a connection
within its connection pool, the second connect() is getting returned the
first handle, _and_ you are resetting AutoCommit on the fly. Because
$db2 and $db1 are references to the same connection in the pool, $db1
will get the attributes you set on $db2.
Peace,
Jamie
Christophe Musielak wrote:
Le jeu 13/11/2003 à 20:08, Perrin Harkins a écrit :
On Thu, 2003-11-13 at 10:32, Christophe Musielak wrote:
My question is : is it safe to use transactions of multiple objects,
doing a commit or rollback at the end as i'm sure i will stay in the
same interpreter space and that no other user can ask for the same
database handle to do some stuff while i'm working?
Yes. Database handles are not shared between interpreters.
Ok
btw, ApacheDBI is always returning me a handle with the default
parameters i used when issuing the connection ( {AutoCommit => 1} for
example), even if i changed the parameters with
local->{dbh}->{AutoCommit} = 0.
Hmmm... Was I talking to you about this on Perlmonks?
Yes
It sounds like maybe you don't understand what local() does, which is
not surprising since hardly anyone does. Any change you make with
local() only lasts for the current scope. If you change things without
local(), it will change the cached handle permanently.
Thanks for your answer Perrin. I tried without local() too and i see
exactly the same result, ie each time i ask DBI via ApacheDBI for a
database handle, i get the handle with the same parameters i created the
handle with, not the ones i just modified, although i can see while
login it's the same handle.
To be clear, as my english not so good :
-
my $db = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
RaiseError => 1 } )||
die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
print "$db"."\n";
print "".$db->{AutoCommit}."\n";
$db->{AutoCommit} = 0;
print "".$db->{AutoCommit}."\n";
my $db2 = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
RaiseError => 1 } )||
die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
print "$db"."\n";
print "".$db->{AutoCommit}."\n";
-
And here is the result :
Database::Dbh = Apache::DBI::db=HASH(0x8f95d28)
Database::Dbh =1
Database::Dbh = # ok AutoCommit Off
Database::Dbh = Apache::DBI::db=HASH(0x8f95d28) # ok same handler
Database::Dbh =1 <<< AutoCommit back On !!
Is this a normal behave of Apache::DBI or am i missing something?
Thanks a lot for your help.
Christophe.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Ongoing problem with random "Handler Not Found"
I've got an existing production system which I've built and maintained over the past 3 years - I've never had a problem with mod_perl until about 4 months ago. During that time I built a new module - PostBlotter.pm, which was not preloaded in startup.pl (I don't typically preload most of our periphery applications). We have about 90% of our 20 modules in a non-preload state, and have never had a problem. However, with this project, PostBlotter and ONLY PostBlotter began exhibiting random (maybe 4 out of 10 requests?) 500 errors - with an error log note of: Undefined subroutine &Apache::MuniCenter::MarkupMatrix::PostBlotter::handler called. And no further information. The cause of this could not be determined, and it was found that setting it to preload in startup.pl completely resolved the problem. Now, a few months later, I've written yet another not-for-preload, periphery process, and I'm seeing the exact same problem, again about 4 out of 10 times: [Mon Nov 17 10:46:43 2003] [error] Undefined subroutine &Apache::MuniCenter::MarkupMatrix::TaxSwap::handler called. Unfortunately, preloading this was not possible - we found that Inline::Java, which we load in for various bond calculation routines, does not behave properly when preloaded, and causes the entire mod_perl system to be unstable; consequently we can't preload this module. At this point I need to know WHY mod_perl randomly can't find the handler, which is properly written, runs through perl -c cleanly, under strict and warnings, and has a 1; at the bottom. Are there any known issues that could cause this? Any easy way to produce a trace of where Apache is looking and what's happening (preferably not a recompile of apache - a trace perl module I can load would be better). This problem exhibits across my development, test/integration, staging, and production environments so it's not a single box issue. Perl version v5.8.1 for Apache/1.3.29 (Unix) mod_perl/1.29 mod_ssl/2.8.16 OpenSSL/0.9.7c Note this problem occurred under Perl 5.6/5.6.1 and Apache 1.3.26, mod_perl 1.26 as well. -- Brendan W. McAdams | [EMAIL PROTECTED] Senior Applications Developer | (646) 375-1140 TheMuniCenter, LLC | www.themunicenter.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: transaction Apache::DBI
On Mon, 2003-11-17 at 09:30, Jamie Le Tual wrote: > An interesting test would be to put a sleep(20) adter the delcaration of > the second database handle, then open a mysql shell and do a : > show processlist; There's no need to go to all that trouble. Turning on debugging for Apache::DBI will tell you when new connection are made. I already tried it, and I can confirm that no new connections are being made. > Because Apache::DBI uses the > DSN/username/password combination to uniquely identify a connection > within its connection pool, the second connect() is getting returned the > first handle, _and_ you are resetting AutoCommit on the fly. Because > $db2 and $db1 are references to the same connection in the pool, $db1 > will get the attributes you set on $db2. That isn't what's happening. Instead, asking for $db2 causes $db1 to return to its original state, before AutoCommit was set. This shouldn't happen, and it doesn't happen when you use connect_cached instead of Apache::DBI. Apache::DBI doesn't make any effort to return database handles to their original state when you call connect. If you change something, it should stay changed. I think there is something strange going on deep within DBI itself. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ongoing problem with random "Handler Not Found"
On Mon, 2003-11-17 at 11:02, Brendan W. McAdams wrote:
> We have about 90% of our 20 modules in a non-preload
> state, and have never had a problem.
Depending on how likely these are to get called and how much they
increase the memory footprint, you might save significant amounts of RAM
by preloading them where possible (i.e. avoiding Inline::Java ones).
> However, with this project, PostBlotter and ONLY PostBlotter began
> exhibiting random (maybe 4 out of 10 requests?) 500 errors - with an
> error log note of:
> Undefined subroutine
> &Apache::MuniCenter::MarkupMatrix::PostBlotter::handler called.
This is just getting called directly by mod_perl when you call a URL
that is mapped to it?
> At this point I need to know WHY mod_perl randomly can't find the
> handler, which is properly written, runs through perl -c cleanly, under
> strict and warnings, and has a 1; at the bottom.
One possible answer is that @INC is different at that time, but it's
hard to find out since the call is being made from C.
> Are there any known issues that could cause this? Any easy way to
> produce a trace of where Apache is looking and what's happening
> (preferably not a recompile of apache - a trace perl module I can load
> would be better).
If you can reproduce it reliably, you can use strace. Another low-tech
approach would be to make a simple handler like this:
package PostBlotterLoader;
use strict;
use warnings;
sub handler {
eval {
require Apache::MuniCenter::MarkupMatrix::PostBlotter;
&Apache::MuniCenter::MarkupMatrix::PostBlotter::handler;
};
if ($@) {
warn "load failure: @INC is " . @INC . " and %INC is " . %INC;
# maybe try again here?
}
}
You can preload that handler, and map the URLs that should go to
PostBlotter to this instead.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
1 server, 2 databases + sites = Mixed calls
Hi everyone
I would search archives for this but I honestly can't think what to
search for in this case :(
I have 1 server, with 2 practically identical sites on it. And calls to
databases are getting mixed up (Using MySQL and DBI)
I have an ensim server running:
Apache/1.3.27
mod_perl/1.24_01
(Red-Hat/Linux)
I'm using PerlAuthenHandler Apache::AuthDBI::authen
I'm calling it like so:
PerlSetVar Auth_DBI_data_source DBI:mysql:angie_mydomain_net
I have my own handler calling my Perl Script for all .html pages:
Action add-vertmod /perl/onefile.pl
AddHandler add-vertmod .html
onfile.pl calls a load of my modules like so:
use lib "/home/virtual/site17/fst/var/www/perl/vert";
use SiteMap;
use Event;
inside my modules I have the following DBI Code
my ($dbname, $host, $user, $password, $tablename) =
qw(angie_mydomain_net localhost username password Event);
my $dbh = DBI->connect("DBI:mysql:$dbname:$host",$user,$password)
or die "can't connect user $user to to database $host:$dbname";
OK that's the setup:
I set up another subdomain on the server, which lives in folder
"/home/virtual/site29"
I changed all references to site17 to site29, and all references to the
database and it's username and password. I've double checked this twice
in BBedit now. I didn't miss any.
So I have one set of modules in
/home/virtual/site17/fst/var/www/perl/vert
and another in
/home/virtual/site29/fst/var/www/perl/vert
And those modules have different database information (but tables inside
are the same).
As you've probably guessed I'm trying to get a mirror site up so I can
work on it while people use the other one safely.
However it seems the database calls are getting mixed up. Sometimes
actions get set to one instead of the other, it's hard to actually say
what is happening, It looks like a var is being overwritten, but I've
used "my" everywhere so I can't work it out.
A bit stuck... Any ideas?
Thanks
Angie
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
On Mon, 2003-11-17 at 12:40, angie ahl wrote: > So I have one set of modules in > /home/virtual/site17/fst/var/www/perl/vert > > and another in > /home/virtual/site29/fst/var/www/perl/vert > > And those modules have different database information (but tables inside > are the same). Sounds like you're having namespace collisions. You can't run two different modules with the same package name in the same interpreter. Take a look at Apache::PerlVINC for a workaround, or run two separate apaches. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
On Mon, 2003-11-17 at 02:15, Christopher P. Lindsey wrote: >I actually get the same results, but I appreciate the idea! Hmmm, then the problem is most likely in the code that you are including. Does it happen if you include a static file instead? Can you try taking things out of your included script to see if the problem goes away? - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
PerlSetVar with '0' value
Hi all,
I have this PerlSetVar behaviour. Suppose to have:
SetHander perl-script
PerlSetVar Something 0
PerlResponseHandler MyModule
But in MyModule.pm, $r->dir_config('Something') returns an undef value instead
of 0 (zero). This happens on both mod_perl generations (I have Perl 5.8.1 with mp
1.29 and mp 1.99_10).
Also I've tried with:
PerlSetVar Something '0'
PerlSetVar Something "0"
My problem is that the my default value of 'Something' isn't 0 and 0 is a
possible value for my module. So, currently I have to code around for example
with:
PerlSetVar Something none
in order to pass a correspondent 0 value.
Maybe it is a known behaviour, but... I've forgotten something in the docs about
it? :-)
I'm surprise of this, because in my Apache (1.x) C modules experience, TAKE1 (or
TAKE2) directive doesn't have the same behaviour returnig args also with 0
values.
by
- Enrico
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
sorry, I sent this yesterday from a different email account but it doesn't look like it went through... Christopher P. Lindsey wrote: Hi, I sent out an email yesterday describing some problems that I'm having with Apache::SSI. I've narrowed things down significantly and hope that this extra info can help someone point me in the right direction. Basically, it all boils down to the fact that once an SSI directive with #EXEC CGI is parsed, the document fails to parse any further SSI directives *if the script to be executed has a perl-script handler.* this is a documented "feature" from the manpage: =head1 CAVEATS * When chaining handlers via Apache::Filter, if you use or , then Apache::SSI must be the last filter in the chain. This is because Apache::SSI uses $r->lookup_uri(...)->run to include the files, and this sends the output through C's stdout rather than Perl's STDOUT. Thus Apache::Filter can't catch it and filter it. for a way around this, see recipe 10.2 in the mod_perl developer's cookbook: http://www.modperlcookbook.org/code/ch10/Cookbook/SSI.pm you can also try Apache::FakeSSI (includes with Apache::SSI) but I haven't tried it myself. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PerlSetVar with '0' value
Enrico Sorcinelli wrote:
Hi all,
I have this PerlSetVar behaviour. Suppose to have:
SetHander perl-script
PerlSetVar Something 0
PerlResponseHandler MyModule
But in MyModule.pm, $r->dir_config('Something') returns an undef value instead
of 0 (zero). This happens on both mod_perl generations (I have Perl 5.8.1 with mp
1.29 and mp 1.99_10).
hmm. PerlSetVar uses apache tables, so I'm not sure whether the problem is
with mod_perl or apache's internal treatment of 0 in C land and the
subsequent perl translation. but I'll look into it for you next week.
thanks for reporting it.
I'm surprise of this, because in my Apache (1.x) C modules experience, TAKE1 (or
TAKE2) directive doesn't have the same behaviour returnig args also with 0
values.
this uses a completely different mechanism :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
Thanks for that, but CPAN seems to indicate that Apache::PerlVINC will have a performance hit (which I need to avoid if possible). would the following work? if the 2 sites call a different directory name eg: site 1: use lib "/home/virtual/site17/fst/var/www/perl/verttemp"; use verttemp::SiteMap; site 2: use lib "/home/virtual/site17/fst/var/www/perl/vert"; use vert::SiteMap; or should that be use lib "/home/virtual/site17/fst/var/www/perl"; ie missing the directory name that corresponds with the module name Have I undestood that concept correctly? Could I still call it via my $page = SiteMap->new; or would I need to say my $page = vert::SiteMap->new; A little find and replacing wouldn't kill me ;) Cheers Angie on 17/11/03 Perrin Harkins said: >On Mon, 2003-11-17 at 12:40, angie ahl wrote: >> So I have one set of modules in >> /home/virtual/site17/fst/var/www/perl/vert >> >> and another in >> /home/virtual/site29/fst/var/www/perl/vert >> >> And those modules have different database information (but tables >inside >> are the same). > >Sounds like you're having namespace collisions. You can't run two >different modules with the same package name in the same interpreter. >Take a look at Apache::PerlVINC for a workaround, or run two separate >apaches. > >- Perrin > > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
On Mon, 2003-11-17 at 13:47, angie ahl wrote: > Thanks for that, but CPAN seems to indicate that Apache::PerlVINC will > have a performance hit (which I need to avoid if possible). It's really for development use. > if the 2 sites call a different directory name eg: > > site 1: > > use lib "/home/virtual/site17/fst/var/www/perl/verttemp"; > use verttemp::SiteMap; > > site 2: > > use lib "/home/virtual/site17/fst/var/www/perl/vert"; > use vert::SiteMap; That will work, if you change the package names inside every file. > Have I undestood that concept correctly? Could I still call it via > > my $page = SiteMap->new; > > or would I need to say > > my $page = vert::SiteMap->new; The latter. > A little find and replacing wouldn't kill me ;) It seems simper to just run two instances of apache. You can just start the same binary twice, with different conf files. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2 -"undefined symbol" in error_log - HOWTO
You are quite welcome. I hope I have more chances to contribute, I feel like I owe a great debt. -Matisse At 9:47 PM -0800 11/14/03, Stas Bekman wrote: Matisse Enzer wrote: Here's a very rough draft of what do do if the error_log includes any "undefined symbol" errors. It's mostly based on Stas' advice for when i had this problem last week. Just perfect, Matisse. I wish my rough drafts were all like this. I've committed it after podifying it and doing a few minor tweaks (mainly formatting). Here it is: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress Muchas gracias, keep those patches coming __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- -- Matisse Enzer Doodlelab Inc. 415-925-5294 ext. 212 (office) 415-225-6703 (mobile) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: strange problem with tied STDIN
SUCH SANMARTÍN, GERARD wrote:
I say strange because i have the next
read(STDIN,$buf,$apache_headers->{'Content-length'});
and it works (when in POST method).
But if i write
$r->read($buf,$apache_headers->{'Content-length'});
then i get no $buf, no data.
I've read some comments about this
http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/Problem_with_tied
_STDIN,_CGI.pm_mod_perl_1.26_and_perl_5.6.1_P7683/
and i like to believe in newest perl - modperl version this is solved.
I use
Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0 Server at localhost
Port 80
This another link
http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/%5Bmp2%5D_POS
T_of_multipart/form-data_broken_in_1.99_10_P88430/
talks about the necessity of use the tied structure rather than the other.
So, any idea?
Please report bugs as explained at:
http://perl.apache.org/bugs/. We need to have a simple test case that we can
reproduce the problem with. Also I'd appreciate if you upgrade first to
1.99_11 or even better the current cvs.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
> > Basically, it all boils down to the fact that once an SSI directive > > with #EXEC CGI is parsed, the document fails to parse any further > > SSI directives *if the script to be executed has a perl-script > > handler.* > > from the manpage: > > * When chaining handlers via Apache::Filter, if you use > or , then Apache::SSI must be the last filter in the > chain. This is because Apache::SSI uses $r->lookup_uri(...)->run to > include the files, and this sends the output through C's stdout rather than > Perl's STDOUT. Thus Apache::Filter can't catch it and filter it. I'm not sure if it's the same problem as I was having (I was using Apache::OutputChain instead because it seems to be more memory-friendly), but switching to Apache::Filter with Apache::SSI *almost* works: SetHandler perl-script PerlSetVar Filter On PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI PerlHandler Apache::RegistryFilter Apache::SSI The problem now is that everything is sent out encoded as text/plain. If I add a line like this AddType text/html .phtml The problem goes away and everything is hunky-dory. But that seems wrong. Is it? Am I missing something? Turning PerlSendHeader On or Off doesn't change things any. > for a way around this, see recipe 10.2 in the mod_perl developer's > cookbook: > > http://www.modperlcookbook.org/code/ch10/Cookbook/SSI.pm Cool, thanks! I'll try to get Apache::Filter working first, but if that doesn't work, it's good to have a fallback. That looks like a great resource. I'm definitely ordering a copy! > > you can also try Apache::FakeSSI (includes with Apache::SSI) but I haven't > tried it myself. Does anyone know how to force Apache::SSIChain to use Apache::FakeSSI instead of Apache::SSI? It was giving me fits. Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
SOLVED (was 'Using SSI with perl handlers?')
> I'm not sure if it's the same problem as I was having (I was using > Apache::OutputChain instead because it seems to be more memory-friendly), > but switching to Apache::Filter with Apache::SSI *almost* works: > > > SetHandler perl-script > PerlSetVar Filter On > PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI > PerlHandler Apache::RegistryFilter Apache::SSI > > > The problem now is that everything is sent out encoded as text/plain. If > I add a line like this > >AddType text/html .phtml D'oh! I hate responding to my own posts, but minutes after sending this I remembered Apache::PassHtml. Changing it to SetHandler perl-script PerlSetVar Filter On PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI PerlHandler Apache::RegistryFilter Apache::PassHtml Apache::SSI makes everything work hunky-dory. Thanks for all of your help, everyone! Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOLVED (was 'Using SSI with perl handlers?')
On Mon, 2003-11-17 at 15:59, Christopher P. Lindsey wrote: > > The problem now is that everything is sent out encoded as text/plain. If > > I add a line like this > > > >AddType text/html .phtml > > D'oh! I hate responding to my own posts, but minutes after sending this > I remembered Apache::PassHtml. Changing it to > > >SetHandler perl-script >PerlSetVar Filter On >PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI >PerlHandler Apache::RegistryFilter Apache::PassHtml Apache::SSI > > > makes everything work hunky-dory. I hate to be a wet blanket, but that looks very wrong to me. Apache::PassHtml does not work with Apache::Filter, so you probably are not running Apache::SSI on these files at all. The problem you were having with headers can be fixed by setting the content-type in your script, which is something you are supposed to do anyway in any web script. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Question about headers and Apache::Filter
On Fri, 2003-11-14 at 14:24, Robert Knaak wrote:
> It seems that PerlSendHeader On has no effect when you are using
> Apache::RegistryFilter, how can I get the proper headed type sent?
Are you still having trouble with this? It looks to me like you can fix
it by adding $r->content_type("text/html") to your scripts, or you can
use an AddType directive in httpd.conf if you don't want to edit your
scripts.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Question about headers and Apache::Filter
Thanks for the info Perrin, I was able to make it work by adding an
AddType.
I am still wondering why every example I see with Apache::RegistryFilter and
Apache::SSI makes no mention of having to set the header.
Robert
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 5:53 PM
To: Robert Knaak
Cc: [EMAIL PROTECTED]
Subject: Re: Question about headers and Apache::Filter
On Fri, 2003-11-14 at 14:24, Robert Knaak wrote:
> It seems that PerlSendHeader On has no effect when you are using
> Apache::RegistryFilter, how can I get the proper headed type sent?
Are you still having trouble with this? It looks to me like you can fix
it by adding $r->content_type("text/html") to your scripts, or you can
use an AddType directive in httpd.conf if you don't want to edit your
scripts.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Question about headers and Apache::Filter
On Mon, 2003-11-17 at 18:41, Robert Knaak wrote: > I am still wondering why every example I see with Apache::RegistryFilter and > Apache::SSI makes no mention of having to set the header. The only time you have to set the header is if you were relying on PerlSendHeader instead of setting the content-type in your script. It definitely should mention the incompatibility with PerlSendHeader. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOLVED (was 'Using SSI with perl handlers?')
> I hate to be a wet blanket, but that looks very wrong to me. > Apache::PassHtml does not work with Apache::Filter, so you probably are > not running Apache::SSI on these files at all. Hi Perrin, You are, of course, right. :) Apache::SSI was being used, but the Content-Type: wasn't being set. My browser (Opera) was just trying to be too smart. After a little nap (hey, I've been spending a lot of hours on this) I looked at things a little more closely. Why PassHtml was making it work with Opera is a mystery to me. > The problem you were having with headers can be fixed by setting the > content-type in your script, which is something you are supposed to do > anyway in any web script. For some reason I'm losing my headers. The script uses CGI.pm; here's the output if I run it on the commandline: Expires: Tue, 18 Nov 2003 04:32:14 GMT Date: Tue, 18 Nov 2003 04:32:14 GMT Pragma: no-cache Content-Type: text/html; charset=ISO-8859-1 However, here's what 'lynx -mime-header -source [URL]' gives me: Date: Tue, 18 Nov 2003 04:40:47 GMT Server: Apache Connection: close Content-Type: text/plain I can use an AddType directive to force .pl files to be sent as text/html, but then I lose my Expires: headers and any others that I may have set. Looks like another long night! (Unless someone has the answer. Please. Someone have the answer!) Thanks for looking at this. Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Build process prompts when PREP_HTTPD=1 is used
Hi, I am building mod_perl using the following: [EMAIL PROTECTED]> perl Makefile.PL \ ? APACHE_SRC=../$apache/src \ ? NO_HTTPD=1 \ ? USE_APACI=1 \ ? PREP_HTTPD=1 \ ? EVERYTHING=1 Will configure via APACI Configure mod_perl with ../apache_1.3.29/src ? [y] Why am I being asked "Configure mod_perl with..."? It seems that since I specified both APACHE_SRC and NO_HTTPD I should not be prompted for more information. I read the documention on these options over an over and I can't figure out why I am getting this prompt. The documentation says this: PREP_HTTPD=1 just means default 'n' to the latter prompt, meaning: Do not build (make) httpd in the Apache source tree. But it will still ask you about Apache's source location even if you have used the APACHE_SRC parameter. Providing the APACHE_SRC parameter will just eliminate the need for perl Makefile.PL to make a guess. To avoid the two prompts: Configure mod_perl with ../apache_1.3.xx/src ? Shall I build httpd in ../apache_1.3.xx/src for you? and avoid building httpd, use: NO_HTTPD=1 -- Wes Barris E-Mail: [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
On Mon, 17 Nov 2003, Christopher P. Lindsey wrote: > Hi, > >I sent out an email yesterday describing some problems that I'm having >with Apache::SSI. I've narrowed things down significantly and hope that >this extra info can help someone point me in the right direction. > >Basically, it all boils down to the fact that once an SSI directive >with #EXEC CGI is parsed, the document fails to parse any further >SSI directives *if the script to be executed has a perl-script >handler.* > this is a documented "feature" from the manpage: =head1 CAVEATS * When chaining handlers via Apache::Filter, if you use or , then Apache::SSI must be the last filter in the chain. This is because Apache::SSI uses $r->lookup_uri(...)->run to include the files, and this sends the output through C's stdout rather than Perl's STDOUT. Thus Apache::Filter can't catch it and filter it. for a way around this, see recipe 10.2 in the mod_perl developer's cookbook: http://www.modperlcookbook.org/code/ch10/Cookbook/SSI.pm you can also try Apache::FakeSSI (includes with Apache::SSI) but I haven't tried it myself. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
ENC: Problem Instaling MOD_PERL for Win32 (Windows 2000)
-Mensagem original- De: Carlos - Fundação MT [mailto:[EMAIL PROTECTED] Enviada em: Monday, November 17, 2003 3:09 PM Para: '[EMAIL PROTECTED]org' Assunto: Problem Instaling MOD_PERL for Win32 (Windows 2000) Good Afternoon, I’d like to install mod_perl for windows 2000, but I donno how search the file mod_perl.zip…. I need to help for you to install the Module Perl for Apache 1.3.29 and Perl 5.6.1 Build 6xx Best Regards, Carlos Augusto Perez Lima
$r losing its class membership
I've encountered a weird, intermittent problem. I have a Perl handler
that handles a certain URL. Sometimes it will fail because the $r
passed to it loses its class.
The handler starts with:
sub handler {
use strict;
my $r = shift;
my $rclass1 = ref $r;
Then, further down:
my $rclass = ref $r;
if($rclass ne 'Apache') {
print STDERR "Transaction2: rclass1='$rclass1' rclass='$rclass' r=" .
Dumper($r);
}
I captured it twice to see where it changes - looks like it's messed up
from the start of the function.
Here's what I see in the error log when the problem occurs. The second
error is caused by invoking $r->header_in.
Transaction2: rclass1='' rclass='' r=$VAR1 = 'PrintMe::Transaction2';
[Thu Nov 13 21:04:55 2003] [error] Can't locate object method "header_in" via package
"PrintMe::Transaction2" (perhaps you forgot to load "PrintMe::Transaction2"?) at
/home/www/www/Libs/PrintMe/Transaction2.pm line 35.
PrintMe::Transaction2 is the name of the handler class.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: ENC: Problem Instaling MOD_PERL for Win32 (Windows 2000)
On Mon, 17 Nov 2003, [iso-8859-1] Carlos - Fundação MT wrote: > I’d like to install mod_perl for windows 2000, but I donno > how search the file mod_perl.zip…. > I need to help for you to install the Module Perl for > Apache 1.3.29 and Perl 5.6.1 Build 6xx The page http://perl.apache.org/docs/1.0/os/win32/install.html#PPM_Packages describes how to install mod_perl by the ppm utility for Win32. -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
