You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by "exlibrismn <exlibrismn@yahoo.com>" <ex...@yahoo.com> on 2003/02/24 19:14:48 UTC
SSI / Filter problem
Howdy,
I am having trouble with controlling the order in which asorted
filters are acting on my pages and how Apache::ASP is acting on them.
I would be grateful for advice. In order, I am attempting to:
1) Run each page through Apache 2.0 external filters to write virtual
include statements at the start of the page body:
ExtFilterDefine header mode=output intype=text/html cmd="/bin/sed
s/<body>/\<!--#include\ virtual=\"\/inc\/header\.inc\"-->/gi" ftype=1
<Directory /home/httpd/html>
ExtFilterOptions LogStderr DebugLevel=0
SetOutputFilter header;INCLUDES
</Directory>
2) Execute code tucked in the body of the included header as part of
a wholly assembled page (I want to use these variables to either turn
on or off certain formatting):
use CGI;
my $query = new CGI;
my $Print = $query->param('Print');
my $self_url=$query->self_url;
My hope was that the virtual includes would be inserted and _then_
the entire assembly would be run through Apache::ASP. Instead,
judging from the values assigned to the variables, ASP is acting on
the header.inc first (i.e. $self_url
is "included://156.98.2.9/index.html" at the time of page display).
The odd thing is that whenever the html page itself contains the
creation of a new CGI object as a part of the page body (about half
the pages on my site), the $self_url successfully picks up the $Print
variable.
How can I force Apache::ASP to process the page after adding the
includes? I have tried assorted things already:
1) Updating the filter chain thusly:
SetOutputFilter header;INCLUDES;perl-script
2) Changing the filter so that it uses the ASP $Responce object:
ExtFilterDefine header mode=output intype=text/html cmd="/bin/sed
s/<body>/\<\%$Response-\>Include(\/inc\/header\.inc\)\;\%\>/gi"
ftype=1
In this case the resulting Perl is not executed, but rather passed to
the browser.
2) Tweeking various parts of my ASP config:
<Files ~ (\.htm|\.inc)>
#<Files ~ (\.htm|)>
SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar Debug 0
PerlSetVar Global .
PerlSetVar NoState 1
PerlSetVar BufferingOn 1
PerlSetVar DynamicIncludes 0
# PerlSetVar DynamicIncludes 1
PerlSetVar CgiHeaders 0
# PerlSetVar Filter On
</Files>
If actually looking at the site would be of any help in helping me, a
page where things seem to be working is:
http://156.98.2.9/issues/index.html
An example of a page giving me frustration:
http://156.98.2.9/index.html
These pages will be up and down as I continue to try solving this
issue myself.
Many thanks for both assistance and for the work put into Apache:ASP.
Andrew Koebrick
Minnesota Planning
Web Coordinator/Librarian
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: SSI / Filter problem
Posted by Josh Chamas <jo...@chamas.com>.
exlibrismn wrote:
> Howdy,
>
> I am having trouble with controlling the order in which asorted
> filters are acting on my pages and how Apache::ASP is acting on them.
> I would be grateful for advice. In order, I am attempting to:
>
> 1) Run each page through Apache 2.0 external filters to write virtual
> include statements at the start of the page body:
>
> ExtFilterDefine header mode=output intype=text/html cmd="/bin/sed
> s/<body>/\<!--#include\ virtual=\"\/inc\/header\.inc\"-->/gi" ftype=1
>
> <Directory /home/httpd/html>
> ExtFilterOptions LogStderr DebugLevel=0
> SetOutputFilter header;INCLUDES
> </Directory>
>
I have not done heavy work with mod_perl 2 yet. Apache::ASP in mod_perl 1.x
would support SSI via Apache::Filter & Apache::SSI. Your best bet
might be if these have been ported to mod_perl 2 now. They would likely
be called ModPerl::Filter now, and your questions here might be more
relevant for the mod_perl users list prefixed with [mp2] in the subject.
Note, that if you use an external filter to try to pipe output into
Apache::ASP for execution, this will likely not work because
Apache::ASP only looks at the script in $r->filename, or whatever
Apache::Filter has coming in for compilation. So to use these
new filters to work with Apache::ASP might take some extra hooks
in Apache::ASP.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org