Re: Apache::SSI pain

[Vassilii Khachaturov]

 third-party CGI stuff which could benefit from mod_perl. Also, how can one
 cope with third party scripts which output their "Content-type:" via usual
 print STDOUT so that it doesn't pop up into the filtered pipeline in
 addition to the one supplied by the Filter mechanism??

After I thought it over, I have got a conclusion that actually, it should be a
problem of PerlRunFilter. IMHO it should (just as Registry does) recognize the
"PerlSendHeader" var. and trim the script headers accordingly.

Re: Apache::SSI pain

[Vassilii Khachaturov]

Hi, I have had a similar problem and didn't overcome it.
I am running apache 1.3.6 and the latest Bundle::Apache, mod-perl-1.21
and Apache::SSI-2.08 (all the dependants are from yesterday's CPAN).

When I use the (deprecated according to this Ken's message)
Apache-OutputChain-0.07, I also have the included file prepended before
the output of the script that spits out the include directive. (I didn't
notice it at first as the rendered output looked just like expected in
my browser -- only the HTML source is messed :-) )

However, when I use Filter as suggested in Apache::Filter(3) (see the
config snippet below), the include directive gets propagated on to the
user agent and not expanded. Try http://win.tarunz.org/test.html to see
:-(

VirtualHost 194.90.246.9
ServerName win.tarunz.org
Options +Includes -Indexes
PerlModule Apache::Filter;
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/win$1 [L]
Directory /home/www/tarunz/perl
Options +ExecCGI
PerlSendHeader On
SetHandler perl-script
PerlSetVar Filter On
#PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
/Directory
/VirtualHost

At http://www.tarunz.org/test.html you see the same thing passing only
the SSI filter w/o the chaining/Filter approach, and at, say,
http://lat.tarunz.org/test.html, you have the wrong order via the
chaining module. Config excerpts of these two vhosts follow.

VirtualHost 194.90.246.9
ServerName www.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch
/VirtualHost

VirtualHost 194.90.246.9
ServerName lat.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/vol$1 [L]
Directory /home/www/tarunz/perl
SetHandler  perl-script
PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Directory
/VirtualHost

What can be wrong?

TIA for any hints,
    Vassilii

 Subject:  Re: Apache::SSI pain
 Author:   Ken Williams [EMAIL PROTECTED]
 Date: Tue, 12 Oct 1999 22:13:54 -0500

 The latest version of Apache::Filter has Apache::PerlRunFilter, which
is (to my
 knowledge) the first Filter-aware version of Registry or PerlRun.  Try
giving
 that a shot.

 The SSIChain  OutputChain side of things isn't so well supported
anymore, it
 may not be worth going in that direction.


 [EMAIL PROTECTED] (Christopher Hicks) wrote:
 I've used the lines below and the various other provided incantations
for
 using Apache::SSI or Apache::SSIChain.
 
 PerlModule Apache::SSIChain
 PerlModule Apache::Filter
 PerlModule Apache::SSI
 PerlModule Apache::OutputChain
 Alias /ssiperl/ /www/perl/ssibin/
 Location /ssiperl
SetHandler perl-script
 #  PerlSendHeader On
PerlSetVar Filter On
 #  PerlHandler Apache::OutputChain Apache::SSIChain
Apache::Registry
 #  PerlHandler Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
Options +ExecCGI
 /Location
 
 The SSI's get included, but they're all at the top of the file.  Both
of
 the PerlHandler lines commented out above have SSIChain as the last
thing
 which is what the docs say to do.  But the includes still get
included
 before the rest of the file.
 
 I've scoured the modperl archives.  I've read through the source and
 documentation to Apache::SSI*.  Does anyone have any ideas?

Re: Apache::SSI pain

[Ken Williams]

One problem is that Apache::Registry doesn't work with Apache::Filter.  You
have to use a modified version (a subclass) to get it to work.  The subclass is
Apache::PerlRunFilter (which is actually a subclass of Apache::PerlRun, not
Apache::Registry, so it doesn't do any caching.  I'll find time sometime to
make a subclass of Registry...), included with Apache::Filter.  So your config
should look something like this:

Directory /home/www/tarunz/perl
 Options +ExecCGI +Includes
 PerlSendHeader On
 SetHandler perl-script
 PerlSetVar Filter On
 PerlHandler Apache::PerlRunFilter Apache::SSI
/Directory


[EMAIL PROTECTED] (Vassilii Khachaturov) wrote:
Hi, I have had a similar problem and didn't overcome it.
I am running apache 1.3.6 and the latest Bundle::Apache, mod-perl-1.21
and Apache::SSI-2.08 (all the dependants are from yesterday's CPAN).

When I use the (deprecated according to this Ken's message)
Apache-OutputChain-0.07, I also have the included file prepended before
the output of the script that spits out the include directive. (I didn't
notice it at first as the rendered output looked just like expected in
my browser -- only the HTML source is messed :-) )

However, when I use Filter as suggested in Apache::Filter(3) (see the
config snippet below), the include directive gets propagated on to the
user agent and not expanded. Try http://win.tarunz.org/test.html to see
:-(

VirtualHost 194.90.246.9
ServerName win.tarunz.org
Options +Includes -Indexes
PerlModule Apache::Filter;
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/win$1 [L]
Directory /home/www/tarunz/perl
Options +ExecCGI
PerlSendHeader On
SetHandler perl-script
PerlSetVar Filter On
#PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
/Directory
/VirtualHost

At http://www.tarunz.org/test.html you see the same thing passing only
the SSI filter w/o the chaining/Filter approach, and at, say,
http://lat.tarunz.org/test.html, you have the wrong order via the
chaining module. Config excerpts of these two vhosts follow.

VirtualHost 194.90.246.9
ServerName www.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch
/VirtualHost

VirtualHost 194.90.246.9
ServerName lat.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/vol$1 [L]
Directory /home/www/tarunz/perl
SetHandler  perl-script
PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Directory
/VirtualHost

What can be wrong?

TIA for any hints,
    Vassilii

 Subject:  Re: Apache::SSI pain
 Author:   Ken Williams [EMAIL PROTECTED]
 Date: Tue, 12 Oct 1999 22:13:54 -0500

 The latest version of Apache::Filter has Apache::PerlRunFilter, which
is (to my
 knowledge) the first Filter-aware version of Registry or PerlRun.  Try
giving
 that a shot.

 The SSIChain  OutputChain side of things isn't so well supported
anymore, it
 may not be worth going in that direction.


 [EMAIL PROTECTED] (Christopher Hicks) wrote:
 I've used the lines below and the various other provided incantations
for
 using Apache::SSI or Apache::SSIChain.
 
 PerlModule Apache::SSIChain
 PerlModule Apache::Filter
 PerlModule Apache::SSI
 PerlModule Apache::OutputChain
 Alias /ssiperl/ /www/perl/ssibin/
 Location /ssiperl
SetHandler perl-script
 #  PerlSendHeader On
PerlSetVar Filter On
 #  PerlHandler Apache::OutputChain Apache::SSIChain
Apache::Registry
 #  PerlHandler Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
Options +ExecCGI
 /Location
 
 The SSI's get included, but they're all at the top of the file.  Both
of
 the PerlHandler lines commented out above have SSIChain as the last
thing
 which is what the docs say to do.  But the includes still get
included
 before the rest of the file.
 
 I've scoured the modperl archives.  I've read through the source and
 documentation to Apache::SSI*.  Does anyone have any ideas?


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: Apache::SSI pain

[Vassilii Khachaturov]

 However, when I use Filter as suggested in Apache::Filter(3) (see the
 config snippet below), the include directive gets propagated on to the
 user agent and not expanded. Try http://win.tarunz.org/test.html to see

oops. It turns out that it has been specifically stated in the docs that
Apache::Registry is not yet filter-aware :-(( Tough luck. (When will
RegistryNG include it?) O.K., meanwhile I will use Apache::PerlRunFilter
instead of Apache::Registry. Nevertheless, I wonder if there is a simple
patch possible to the OutputChain to fix the other way :-( I don't want to
miss the caching support of ::Registry in the general case for some
third-party CGI stuff which could benefit from mod_perl. Also, how can one
cope with third party scripts which output their "Content-type:" via usual
print STDOUT so that it doesn't pop up into the filtered pipeline in
addition to the one supplied by the Filter mechanism??

Of course, for my case I do have several workarounds. E.g., the script can
be easily converted to a proper handler without a need to wrap it by all
this Registry/etc stuff. It will improve the performance, won't it?

I will notify this thread when I close the published links/alter the configs
-- and tell which solution was better and why.

To future archive visitors: check if Apache::Registry supports Filter at the
time you read this, then all my pain with the "Filter" version is
obsolete...

V.

Re: Apache::SSI pain

[Perrin Harkins]

The thing that works best for me is to use an Apache::SSI object myself
rather than using any kind of chaining.

  my $ssi = Apache::SSI-new($text, $r);
  print $q-header; # send the HTTP header
  $ssi-output();

Or you can capture the output instead of just sending it, like this:

  my $ssi= Apache::SSI-new($text, $r);
  my $result = $ssi-get_output();

I actually do this with a customized subclass that implements some
site-specific SSI directives.  I'm calling it from within a custom
handler, and not inside any kind of Registry or PerlRun script.  Works
perfectly for me.  YMMV.

- Perrin

Christopher Hicks wrote:
 
 I've used the lines below and the various other provided incantations for
 using Apache::SSI or Apache::SSIChain.
 
 PerlModule Apache::SSIChain
 PerlModule Apache::Filter
 PerlModule Apache::SSI
 PerlModule Apache::OutputChain
 Alias /ssiperl/ /www/perl/ssibin/
 Location /ssiperl
 SetHandler perl-script
 #   PerlSendHeader On
 PerlSetVar Filter On
 #   PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
 #   PerlHandler Apache::SSIChain Apache::Registry
 PerlHandler Apache::Registry Apache::SSI
 Options +ExecCGI
 /Location
 
 The SSI's get included, but they're all at the top of the file.  Both of
 the PerlHandler lines commented out above have SSIChain as the last thing
 which is what the docs say to do.  But the includes still get included
 before the rest of the file.
 
 I've scoured the modperl archives.  I've read through the source and
 documentation to Apache::SSI*.  Does anyone have any ideas?
 
 My workaround:
 
 sub processSSI {
 my ($text,$r) = @_;
 
 my @lines = split(/\n/,$text);
 
 my ($line,@el,$command,$key,$val,%param);
 
 foreach $line (@lines) {
 if ($line =~ /!--#(.*)--/) {
 @el = split(/\s+/,$1);
 $command = lc(shift(@el));
 foreach (@el) {
 ($key,$val) = split(/=/);
 $key = lc($key); # lower case key
 
 # strip double quotes if they're there
 # and balanced
 if (substr($val,0,1) eq '"') {
 if (substr($val,-1,1) eq '"') {
 chop($val);
 substr($val,0,1) = '';
 }
 }
 $param{$key}=$val;
 }
 if ($command eq "include") {
 if (defined( $param{'virtual'} )) {
 Apache::Include-virtual($param{'virtual'});
 }
 }
 } else {
 print $line, "\n";
 }
 }
 }
 
 This handles my needs.  It is a disadvantage to be stuck with putting
 anything that isn't an "include virtual" into a file which is then called
 via an "include virtual".  But at least it works.
 
 --
 /chris
 
 "The only thing more frightening than a programmer with a screwdriver
 or a hardware enginner with a program is a user with wire cutters and
 the root password."- Elizabeth Zwicky

Apache::SSI pain

[Christopher Hicks]

I've used the lines below and the various other provided incantations for
using Apache::SSI or Apache::SSIChain.

PerlModule Apache::SSIChain
PerlModule Apache::Filter
PerlModule Apache::SSI
PerlModule Apache::OutputChain
Alias /ssiperl/ /www/perl/ssibin/
Location /ssiperl
SetHandler perl-script
#   PerlSendHeader On
PerlSetVar Filter On
#   PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
#   PerlHandler Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
Options +ExecCGI
/Location

The SSI's get included, but they're all at the top of the file.  Both of
the PerlHandler lines commented out above have SSIChain as the last thing
which is what the docs say to do.  But the includes still get included
before the rest of the file.

I've scoured the modperl archives.  I've read through the source and
documentation to Apache::SSI*.  Does anyone have any ideas?

My workaround:

sub processSSI {
my ($text,$r) = @_;

my @lines = split(/\n/,$text);

my ($line,@el,$command,$key,$val,%param);

foreach $line (@lines) {
if ($line =~ /!--#(.*)--/) {
@el = split(/\s+/,$1);
$command = lc(shift(@el));
foreach (@el) {
($key,$val) = split(/=/);
$key = lc($key); # lower case key

# strip double quotes if they're there
# and balanced
if (substr($val,0,1) eq '"') {
if (substr($val,-1,1) eq '"') {
chop($val);
substr($val,0,1) = '';
}
}
$param{$key}=$val;
}
if ($command eq "include") {
if (defined( $param{'virtual'} )) {
Apache::Include-virtual($param{'virtual'});
}
}
} else {
print $line, "\n";
}
}
}

This handles my needs.  It is a disadvantage to be stuck with putting
anything that isn't an "include virtual" into a file which is then called
via an "include virtual".  But at least it works.

-- 
/chris

"The only thing more frightening than a programmer with a screwdriver
or a hardware enginner with a program is a user with wire cutters and
the root password."- Elizabeth Zwicky