On Wed, May 16, 2001 at 08:15:50PM -0700, Doug MacEachern wrote:
> On Wed, 16 May 2001, barries wrote:
>
> > What's the philosophy behind the naming of InputMessageFilter and
> > InputBodyFilter, which seem to correspond to input connection filters
> > (ie for the headers) and input request filters (ie for the content).
>
> that's the idea. InputMessageFilter needs to be per-server,
> InputBodyFilter can be per-{directory,location,files,etc}
> rather than have 5 different directives for each input filter type, i
> wanted to have 1 and attributes can be used to specify the type.
> with InputBodyFilter (AP_FTYPE_CONTENT) being the default.
*click* thanks. "message" != "connection" and "body" != "content" threw
me off. "body" makes some sense to me, but why "message"?
Should this bit of httpd.conf:
PerlSwitches -MMy::InputFilter1 -MFoo -MFooHandler
<Location /*>
SetHandler modperl
PerlInputFilterHandler My::InputFilter1
PerlOutputFilterHandler Foo
PerlResponseHandler FooHandler
</Location>
along with this in lib/My/InputFilter1.pm:
package My::InputFilter1 ;
use Apache::Filter ;
use base qw( Apache::Filter ) ;
sub handler: InputFilterBody {
die ;
}
be suicidal at this point? I see that t/* tests InputBodyFilter
functionality, but I also see a recent post on new-htpd that input
filters seem a little screwed. In the above config, the handler and
output filter both run, but the input filter doesn't.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
