You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Christopher P. Lindsey" <li...@mallorn.com> on 2003/11/17 07:36:16 UTC

Using SSI with perl handlers?

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.*

   If I put the lines

      print q(<!--#EXEC CGI="/perl/navbar.pl" -->), "\n";
      print q(<!--#EXEC CGI="/perl/navbar.pl" -->), "\n";

   at the top of my perl script, the first SSI gets parsed.  If it points
   to another include file that has lots of sub-levels, each with their own
   CGI scripts, they're all run fine.  It just stops parsing once it finishes
   with the first one.

   The files that are being included are handled like so:

      <Location /perl/>
         SetHandler perl-script
         PerlModule Apache::Registry
         PerlHandler Apache::Registry
      </Location>

   They're included from other HTML and CGI scripts via SSI without problems.

   But if I have a script handled by mod_perl, configured like

      <Files *.pl>
         SetHandler perl-script
         PerlModule Apache::OutputChain Apache::SSIChain Apache::Registry
         PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
      </Files>

   with two SSI directives like I first listed above, only the first is
   parsed.

   What do I need to do?  I've tried Apache::Filter with the same results, 
   so I'm guessing that I missed an important step at a more basic level.
   Please, help!

Thanks,

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?')

Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2003-11-18 at 02:12, Christopher P. Lindsey wrote:
> Basically, adding these lines to my perl script made it all better:
> 
>    my $r = Apache->request;
>    $r->content_type('text/html');
>    $r->no_cache(1);

Good.  Don't forget, you can look at the source.  Apache::Filter is
pretty short, and if you look at it you'll see that it calls
$r->send_http_header() at the end.  Unfortunately, I think this means
that it doesn't work with CGI.pm, since send_http_header() doesn't know
what CGI.pm set the content-type to.

> The only other question that I'm left with now is why I get these lines
> in my error log regularly:
> 
>    Subroutine Apache::send_http_header redefined at /usr/local/perl/lib/site_perl/5.8.0/Apache/RegistryFilter.pm line 48, <GEN0> line 1.
>    Subroutine Apache::send_cgi_header redefined at /usr/local/perl/lib/site_perl/5.8.0/Apache/RegistryFilter.pm line 49, <GEN0> line 1.

Apache::RegistryFilter temporarily overrides those methods in your
script.  If you don't use those methods anyway, you could comment out
that section of Apache::RegistryFilter, or stick with your 'no warnings'
solution.

- 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?')

Posted by "Christopher P. Lindsey" <li...@mallorn.com>.
>    However, here's what 'lynx -mime-header -source [URL]' gives me:
> 
>       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.

OK, here I go following up on my own message again.  In another thread
you refered to setting $r->content_type() as a possible solution.  The
mod_perl O'Reilly book that I'm using goes into some detail about it
too, but I couldn't figure out where $r came from (hey, I've only used
mod_perl for a few days now ;)

Anyhow, this Web page was a big help:

   http://www.webreference.com/programming/perl/mod_perl/chap6/4/4.html

Basically, adding these lines to my perl script made it all better:

   my $r = Apache->request;
   $r->content_type('text/html');
   $r->no_cache(1);

The only other question that I'm left with now is why I get these lines
in my error log regularly:

   Subroutine Apache::send_http_header redefined at /usr/local/perl/lib/site_perl/5.8.0/Apache/RegistryFilter.pm line 48, <GEN0> line 1.
   Subroutine Apache::send_cgi_header redefined at /usr/local/perl/lib/site_perl/5.8.0/Apache/RegistryFilter.pm line 49, <GEN0> line 1.

I added 

   no warnings 'redefine';

to the top of RegistryFilter.pm for now (which solved that problem), but is
there a better way to handle this?

Thanks,

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?')

Posted by "Christopher P. Lindsey" <li...@mallorn.com>.
> 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

Re: SOLVED (was 'Using SSI with perl handlers?')

Posted by Perrin Harkins <pe...@elem.com>.
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
> 
>     <Files ~ "\.phtml$">
>        SetHandler perl-script
>        PerlSetVar Filter On
>        PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI
>        PerlHandler Apache::RegistryFilter Apache::PassHtml Apache::SSI
>     </Files>
> 
> 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

SOLVED (was 'Using SSI with perl handlers?')

Posted by "Christopher P. Lindsey" <li...@mallorn.com>.
> 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:
> 
>    <Files ~ "\.phtml$">
>       SetHandler perl-script
>       PerlSetVar Filter On
>       PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI
>       PerlHandler Apache::RegistryFilter Apache::SSI
>    </Files>
> 
> 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

    <Files ~ "\.phtml$">
       SetHandler perl-script
       PerlSetVar Filter On
       PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI
       PerlHandler Apache::RegistryFilter Apache::PassHtml Apache::SSI
    </Files>

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: Using SSI with perl handlers?

Posted by "Christopher P. Lindsey" <li...@mallorn.com>.
> >   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 <!--#include...-->
> or <!--#exec cgi=...-->, 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:

   <Files ~ "\.phtml$">
      SetHandler perl-script
      PerlSetVar Filter On
      PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI
      PerlHandler Apache::RegistryFilter Apache::SSI
   </Files>

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

Re: Using SSI with perl handlers?

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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 <!--#include...-->
or <!--#exec cgi=...-->, 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: Using SSI with perl handlers?

Posted by Perrin Harkins <pe...@elem.com>.
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

Re: Using SSI with perl handlers?

Posted by "Christopher P. Lindsey" <li...@mallorn.com>.
> 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: Using SSI with perl handlers?

Posted by Perrin Harkins <pe...@elem.com>.
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?

Posted by Geoffrey Young <gy...@secure.exclamationlabs.net>.

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 <!--#include 
...-->
or <!--#exec cgi=...-->, 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