Apache-Filter

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    * $r->deterministic(1|0);
        As of version 0.07, the concept of a "deterministic" filter is
        supported. A deterministic filter is one whose output is entirely
        determined by the contents of its input file (whether the $r->filename
        file or the output of another filter), and doesn't depend at all on
        outside factors. For example, a filter that translates all its output to
        upper-case is deterministic, but a filter that adds a date stamp to a
        page, or looks things up in a database which may vary over time, is not.

        Why is this a big deal? Let's say you have the following setup:

         <Files ~ "\.boffo$">
          SetHandler perl-script
          PerlSetVar Filter On
          PerlHandler Apache::FormatNumbers Apache::DoBigCalculation
          # The above are fake modules, you get the idea
         </Files>

        Suppose the FormatNumbers module is deterministic, and the
        DoBigCalculation module takes a long time to run. The DoBigCalculation

README  view on Meta::CPAN

HEADERS
    In previous releases of this module, it was dangerous to call
    $r->send_http_header(), because a previous/postvious filter might also try
    to send headers, and then you'd have duplicate headers getting sent. In
    current releases you can simply send the headers. If the current filter is
    the last filter, the headers will be sent as usual, and otherwise
    send_http_header() is a no-op.

NOTES
    You'll notice in the SYNOPSIS that I say ""PerlSetVar Filter On"". That
    information isn't actually used by this module, it's used by modules which
    are themselves filters (like Apache::SSI). I hereby suggest that filtering
    modules use this parameter, using it as the switch to detect whether they
    should call $r->filter_register. However, it's often not necessary - there
    is very little overhead in simply calling $r->filter_register even when you
    don't need to do any filtering, and $r->filter_input can be a handy way of
    opening the $r->filename file.

    VERY IMPORTANT: if one handler in a stacked handler chain uses
    "Apache::Filter", then THEY ALL MUST USE IT. This means they all must call

lib/Apache/Filter.pm  view on Meta::CPAN

=item * $r->deterministic(1|0);

As of version 0.07, the concept of a "deterministic" filter is supported.  A
deterministic filter is one whose output is entirely determined by the contents
of its input file (whether the $r->filename file or the output of another filter),
and doesn't depend at all on outside factors.  For example, a filter that translates
all its output to upper-case is deterministic, but a filter that adds a date
stamp to a page, or looks things up in a database which may vary over time, is not.

Why is this a big deal?  Let's say you have the following setup:

 <Files ~ "\.boffo$">
  SetHandler perl-script
  PerlSetVar Filter On
  PerlHandler Apache::FormatNumbers Apache::DoBigCalculation
  # The above are fake modules, you get the idea
 </Files>

Suppose the FormatNumbers module is deterministic, and the DoBigCalculation module
takes a long time to run.  The DoBigCalculation module can now cache its results,

lib/Apache/Filter.pm  view on Meta::CPAN

In previous releases of this module, it was dangerous to call
$r->send_http_header(), because a previous/postvious filter might also
try to send headers, and then you'd have duplicate headers getting
sent.  In current releases you can simply send the headers.  If the
current filter is the last filter, the headers will be sent as usual,
and otherwise send_http_header() is a no-op.

=head1 NOTES

You'll notice in the SYNOPSIS that I say C<"PerlSetVar Filter On">.  That
information isn't actually used by this module, it's used by modules which
are themselves filters (like Apache::SSI).  I hereby suggest that filtering
modules use this parameter, using it as the switch to detect whether they 
should call $r->filter_register.  However, it's often not necessary -
there is very little overhead in simply calling $r->filter_register
even when you don't need to do any filtering, and $r->filter_input can
be a handy way of opening the $r->filename file.

VERY IMPORTANT: if one handler in a stacked handler chain uses 
C<Apache::Filter>, then THEY ALL MUST USE IT.  This means they all must