On Thu, 17 May 2001, barries wrote:
> *click* thanks. "message" != "connection" and "body" != "content" threw
> me off. "body" makes some sense to me, but why "message"?
because an InputMessageFilter filters the whole HTTP message, headers +
body. InputBodyFilter filters only the body. from rfc2068 section 4
"HTTP Message":
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
is where the names 'message' and 'body' filter come from.
we could also have an InputHeaderFilter that is removed after the headers
have been read. i suppose the 'body' attribute could be renamed to
'content', but not too concerned about the names at this point.
> 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.
you have to POST some data and have it be read by your response handler
for the body filter to run.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
