Re: SSI advocacy Was:: Multiple AddHandler statements
Joachim Zobel wrote: Including If-Modified-Since - 304 responding? No, none of them handle that (well, AxKit?), probably because most sites need to do more than stat-ing the template files to determine if the page content has been modified. A site with no dynamic content could be pre-generated with a make-like procedure and served statically. In fact my main objection to the majority of templating systems is that they are frameworks. I am using a homegrown template engine at the moment and probably would be using template toolkit if I started now, but I definitely hate to be framed at work:) Template Toolkit, Text::Template, and HTML::Template are all pretty good at staying out of your way. They're not frameworks like Mason and Embperl. But hey, if you like SSI then go ahead and use it. It's good at what it does. I was just pointing out that the templating tools are pretty solid as well. - Perrin
Re: SSI Lost with Mod Perl?
Brooklyn Linux Solutions CEO wrote: I have modules controlling all the files and their access and content in the directy. I have no idea really why SSI is shut down. I never used it before. It looks like you're trying to post-process the output of a PerlHandler with SSI. The only way to do that is by using Apache::SSI and Apache::Filter, as described here: http://search.cpan.org/doc/KWILLIAMS/Apache-SSI-2.16/SSI.pm - Perrin
Re: Directory Restrictions
On Sat, Jun 23, 2001 at 11:10:07PM -0400, Brooklyn Linux Solutions CEO wrote:
I've been working on a mod_perl implimentation which
does the following.
...
I have something like this running on the top directory:
sub handler{
my $r = shift;
return DECLINED if ($r-uri() =~ /top/home.html);
return DECLINED if ($r-uri() =~ /top/login.html);
return DECLINED if ($r-uri() =~ /top/lower_dir1);
return DECLINED if ($r-uri() =~ /top/lower_dir2);
return DECLINED if (!$r-content_type('text/html));
return DECLINED if ($r-content_type('images/gif));
i bet you mistyped some of that...
val =~ /pattern/flags
maybe something more like:
return DECLINED
if ($r-uri() =~ m{/top/((home|login).html|lower_dir[12])});
It's doing an internal redirect when they are autorized for on of the
lower directories, but the graphics are still now getting through
to the top if I remove the DECLINED content_type 'text/html'. But when
I leave it in, they seem to have access to the directory access.
hmm -- ! text/html should make images/gif redundant, i'd
think. anybody got a pointer, here?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, Some Came Running
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
head/HEAD - mod_perl install on darwin/mac osx
hello , i just read a posting in the mod_perl list archive: i have compiled apache 1_3.20 and perl 5.6.1 problemless. i have also installed the nesecary modules before mod_perl and now want to build mod_perl itself. im aware of the head/HEAD problem that comes with LWP on mac osX and have therefore copied a binary head that ken williams sent me into /usr/bin and moved the lwp head into /usr/local/bin. it is referring to a head/HEAD problem and a binary that solves it. does anyone know where i can find this binary?? i couldn't find any other traces of it in the mailing list archive... thanks chris
Re: SSI advocacy Was:: Multiple AddHandler statements
On Sunday 24 June 2001 11:55, Perrin Harkins wrote: Joachim Zobel wrote: Including If-Modified-Since - 304 responding? No, none of them handle that (well, AxKit?), probably because most sites need to do more than stat-ing the template files to determine if the page content has been modified. Yes, AxKit will send 304s properly for anything that can be cached. Adding your own caching (according to whatever rules you want) is easy. That's a big performance boost imho if you have a way to tell whether your content has changed or not. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- It's better to be quotable than to be honest. -- Tom Stoppard
Re: Directory Restrictions
One thing that is not clear in my mind is the type of
page which is sent back with a directory index.
A directory index is of what mime type?
Ruben
On Sat, Jun 23, 2001 at 11:10:07PM -0400, Brooklyn Linux Solutions CEO wrote:
I've been working on a mod_perl implimentation which
does the following.
...
I have something like this running on the top directory:
sub handler{
my $r = shift;
return DECLINED if ($r-uri() =~ /top/home.html);
return DECLINED if ($r-uri() =~ /top/login.html);
return DECLINED if ($r-uri() =~ /top/lower_dir1);
return DECLINED if ($r-uri() =~ /top/lower_dir2);
return DECLINED if (!$r-content_type('text/html));
return DECLINED if ($r-content_type('images/gif));
i bet you mistyped some of that...
val =~ /pattern/flags
maybe something more like:
return DECLINED
if ($r-uri() =~ m{/top/((home|login).html|lower_dir[12])});
It's doing an internal redirect when they are autorized for on of the
lower directories, but the graphics are still now getting through
to the top if I remove the DECLINED content_type 'text/html'. But when
I leave it in, they seem to have access to the directory access.
hmm -- ! text/html should make images/gif redundant, i'd
think. anybody got a pointer, here?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, Some Came Running
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: SSI Lost with Mod Perl?
IS there a way of pre-processing and post processing a handler? Ruben Brooklyn Linux Solutions CEO wrote: I have modules controlling all the files and their access and content in the directy. I have no idea really why SSI is shut down. I never used it before. It looks like you're trying to post-process the output of a PerlHandler with SSI. The only way to do that is by using Apache::SSI and Apache::Filter, as described here: http://search.cpan.org/doc/KWILLIAMS/Apache-SSI-2.16/SSI.pm - Perrin
Re: SSI Lost with Mod Perl?
IS there a way of pre-processing and post processing a handler? Only by using something like Apache::Filter. Apache itself does not support chaining handlers. - Perrin
Re: which perl?
On Sun, 24 Jun 2001, Stas Bekman wrote: On Sun, 24 Jun 2001, Brooklyn Linux Solutions CEO wrote: It's got to be built in. My mod_perl conf keeps looking in 5.6.0 in the @INC array even after the 5.6.1 upgrade I got sick of the problem and linked 5.6.1 into 5.6.0 You could achieve the same with: startup.pl: --- use lib qw(/usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1); note that lib.pm takes care of adding the arch lib paths (i686-linux on my machine) and removing dups. interesting. I created a symlink to my 5.6.1 binary, and I am pointing to the 5.6.1 libraries within my PerlRequire script (in my case it's mason's handler.pl)... and yet, modperl is still using 5.6.0! I am really at a loss... I'm really hoping i won't have to rebuild mod_perl as this particular server is using a pre-built SSL version we don't want to break ;) but would that even help? Is sounds like it shouldn't be necessary. thanks todd
Re: which perl?
On Sun, 24 Jun 2001, Todd Goldenbaum wrote: On Sun, 24 Jun 2001, Stas Bekman wrote: On Sun, 24 Jun 2001, Brooklyn Linux Solutions CEO wrote: It's got to be built in. My mod_perl conf keeps looking in 5.6.0 in the @INC array even after the 5.6.1 upgrade I got sick of the problem and linked 5.6.1 into 5.6.0 You could achieve the same with: startup.pl: --- use lib qw(/usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1); note that lib.pm takes care of adding the arch lib paths (i686-linux on my machine) and removing dups. interesting. I created a symlink to my 5.6.1 binary, and I am pointing to the 5.6.1 libraries within my PerlRequire script (in my case it's mason's handler.pl)... and yet, modperl is still using 5.6.0! I am really at a loss... I'm really hoping i won't have to rebuild mod_perl as this particular server is using a pre-built SSL version we don't want to break ;) but would that even help? Is sounds like it shouldn't be necessary. check the order of paths in @INC. If 5.6.0 is coming first, that explains your problem. try: perl -le 'print join \n, @INC' but this is your perl with no @INC adjustments. do the same from some simple CGI script /server-status via Apache::Status is another way to check (See the guide or the manpage) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: which perl?
On Sun, 24 Jun 2001, Todd Goldenbaum wrote: On Sun, 24 Jun 2001, Stas Bekman wrote: On Sun, 24 Jun 2001, Brooklyn Linux Solutions CEO wrote: It's got to be built in. My mod_perl conf keeps looking in 5.6.0 in the @INC array even after the 5.6.1 upgrade I got sick of the problem and linked 5.6.1 into 5.6.0 You could achieve the same with: startup.pl: --- use lib qw(/usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1); note that lib.pm takes care of adding the arch lib paths (i686-linux on my machine) and removing dups. interesting. I created a symlink to my 5.6.1 binary, and I am pointing to the 5.6.1 libraries within my PerlRequire script (in my case it's mason's handler.pl)... and yet, modperl is still using 5.6.0! also notice that this will work only if your libs are binary compatible. did you make 4 symlinks? I've numbered these below as 1-4 mine is: $ perl -V Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES Built under linux Compiled at Apr 20 2001 22:58:59 @INC: 1/usr/lib/perl5/5.6.1/i686-linux 2/usr/lib/perl5/5.6.1 3/usr/lib/perl5/site_perl/5.6.1/i686-linux 4/usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.005 /usr/lib/perl5/site_perl . I am really at a loss... I'm really hoping i won't have to rebuild mod_perl as this particular server is using a pre-built SSL version we don't want to break ;) but would that even help? Is sounds like it shouldn't be necessary. thanks todd _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: which perl?
On Mon, 25 Jun 2001, Stas Bekman wrote: On Sun, 24 Jun 2001, Todd Goldenbaum wrote: On Sun, 24 Jun 2001, Stas Bekman wrote: On Sun, 24 Jun 2001, Brooklyn Linux Solutions CEO wrote: It's got to be built in. My mod_perl conf keeps looking in 5.6.0 in the @INC array even after the 5.6.1 upgrade I got sick of the problem and linked 5.6.1 into 5.6.0 You could achieve the same with: startup.pl: --- use lib qw(/usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1); note that lib.pm takes care of adding the arch lib paths (i686-linux on my machine) and removing dups. interesting. I created a symlink to my 5.6.1 binary, and I am pointing to the 5.6.1 libraries within my PerlRequire script (in my case it's mason's handler.pl)... and yet, modperl is still using 5.6.0! also notice that this will work only if your libs are binary compatible. did you make 4 symlinks? I've numbered these below as 1-4 mine is: $ perl -V Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES Built under linux Compiled at Apr 20 2001 22:58:59 @INC: 1/usr/lib/perl5/5.6.1/i686-linux 2/usr/lib/perl5/5.6.1 3/usr/lib/perl5/site_perl/5.6.1/i686-linux 4/usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.005 /usr/lib/perl5/site_perl actually yes, they appear to be in the right order: $ perl -V Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at May 23 2001 08:18:14 @INC: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl and yet, mod perl is still showing that it's using 5.6.0...
Re: which perl?
Todd, Perl and mod_perl are separate entities altogether. Perl is the scripting language. mod_perl is an extension to Apache, which builds a Perl interpreter into the Apache webserver. The binary components are mostly separate, e.g. you could theoretically run Perl and mod_perl at different versions; the actual perl binary and the mod_perl extensions are separate. However, the Perl interpreter built into the Apache webserver, plus all the associated Perl modules that implement mod_perl's functionality, inherit all the characteristics of the Perl it was built against--bugs in the interpreter, language characteristics, or where to find libraries. In your case it sounds like your mod_perl is built for a different version of Perl. As several others have suggested, the best way is to rebuild mod_perl so it is built against your version of Perl. Another easier to do it would be to use your vendor's package system, for example if you are using RedHat or Debian, you may be able to find Perl and mod_perl packages (RPMs or whatnot) and install them to fix the versioning issues. I still recommend building it; for the base case, it's pretty easy to do. Follow the all-in-one directions in the mod_perl download and it usually Just Works. The symlinking and changing the @INC path may work, but this is a hacky, symptomatic solution at best. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: which perl?
I recommend whatever stas is saying. Ruben actually yes, they appear to be in the right order: $ perl -V Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at May 23 2001 08:18:14 @INC: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl and yet, mod perl is still showing that it's using 5.6.0... note- the results i get from a script running under mod_perl is slightly different, but 5.6.1 is indeed first. (this is the output of @INC) /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl i may have misunderstood- were you recommending that i actually delete these 5.6.0 directories, and symlink them over to the 5.6.1 equivs?
Re: Directory Restrictions
When you get a directory index, what Mime type is that? Ruben
Re: which perl?
Hello, RReally R RI asked this question and didn't get much of an answer from folks other Rthan they THOUGHT it was built in the perl binary. RI recommend whatever stas is saying. Stop being an ass, and maybe people will help you out. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Directory Restrictions
On Sunday 24 June 2001 20:23, Brooklyn Linux Solutions CEO wrote: When you get a directory index, what Mime type is that? httpd/unix-directory Maybe it's different in windows, I don't know. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Sex is not the answer. Sex is the question. Yes is the answer.
Can I use mod_perl to monitor mod_ssl
Hi. We are having infrequent non reproducable problems with SSL. Can I use mod_perl for debugging and monitoring the SSL activity beyond HTTP? Thanx, Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
Re: Directory Restrictions
thanks I didn't see that in the mine.types Ruben On Sunday 24 June 2001 20:23, Brooklyn Linux Solutions CEO wrote: When you get a directory index, what Mime type is that? httpd/unix-directory Maybe it's different in windows, I don't know. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Sex is not the answer. Sex is the question. Yes is the answer.
Re: which perl?
On Sun, 24 Jun 2001, Todd Goldenbaum wrote: actually yes, they appear to be in the right order: $ perl -V Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at May 23 2001 08:18:14 @INC: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl and yet, mod perl is still showing that it's using 5.6.0... note- the results i get from a script running under mod_perl is slightly different, but 5.6.1 is indeed first. (this is the output of @INC) /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl i may have misunderstood- were you recommending that i actually delete these 5.6.0 directories, and symlink them over to the 5.6.1 equivs? It's me who wasn't clear. Of course perl -V is not what you want. I just suggested it as an example to see what your @INC under mod_perl should be like. So grab the output of perl -V, and put it in use lib qw(HERE); in startup.pl now make sure that 5.6.1's 4 directories are coming up first in @INC. As you can see your output is missing i386-linux dirs for 5.6.1. remove the symlinks. ALso I repeat that this won't work if your 5.6.0 is binary incompatible with 5.6.1 (which is the case if you've changed build args, like enable/disable threads and similar). Of course the best thing is to recompile :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: which perl?
Thanks Andrew- good stuff. You've convinced me, I'm just going to bite the bullet and rebuild :) todd On Sun, 24 Jun 2001, Andrew Ho wrote: Todd, Perl and mod_perl are separate entities altogether. Perl is the scripting language. mod_perl is an extension to Apache, which builds a Perl interpreter into the Apache webserver. The binary components are mostly separate, e.g. you could theoretically run Perl and mod_perl at different versions; the actual perl binary and the mod_perl extensions are separate. However, the Perl interpreter built into the Apache webserver, plus all the associated Perl modules that implement mod_perl's functionality, inherit all the characteristics of the Perl it was built against--bugs in the interpreter, language characteristics, or where to find libraries. In your case it sounds like your mod_perl is built for a different version of Perl. As several others have suggested, the best way is to rebuild mod_perl so it is built against your version of Perl. Another easier to do it would be to use your vendor's package system, for example if you are using RedHat or Debian, you may be able to find Perl and mod_perl packages (RPMs or whatnot) and install them to fix the versioning issues. I still recommend building it; for the base case, it's pretty easy to do. Follow the all-in-one directions in the mod_perl download and it usually Just Works. The symlinking and changing the @INC path may work, but this is a hacky, symptomatic solution at best. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
