which handler?!?

["J. Horner" <jh...@2jnetworks.com>]

I'm finally writing the web server intrusion system that I've planned for
months.  I have the skeleton for the URI comparing handler, but I'm a
little unclear where it should really go.

A handler is written to compare the URI against a source of known web
server issues to alert the administrator to hacking attempts.  Should the
handler be installed at the PerlPostReadRequestHandler phase or the
PerlTransHandler phase.  The Eagle book says something like:

"It is called once per transaction and is intended to allow modules to
step in and perform special processing on the incoming data", which is
what I want, but it goes on to say, "However, because there's no way for
modules to step in and actually contribute to the parsing of the HTTP
header, this phase is more often  used just as a convenient place to do
processing that must occur once per transaction."  

Is this last sentence not the negation that I read it to be?  It seems to
me that it is telling me that I really can't write a handler to actually
do something useful on the incoming request header.  

If I put the hander in at PerlTransHandler, it seems that I would
interfere unnecessarily at the translation phase.  I just want a place to
put it where it can take the request, run a regexp against a list of known
issues to check for a match, then, if we return a false, go on with the
parsing and file mapping.

Ideas?  Doug?  Lincoln?  Can I get some clarification?

J. J. Horner
Linux, Apache, Perl, Unix, Stronghold
jhorner@knoxlug.org http://www.knoxlug.org
System has been up: 4 days.

Re: which handler?!?

[Kevin Murphy <ke...@boojiboy.eorbit.net>]

"J. Horner" wrote:
> "It is called once per transaction and is intended to allow modules to
> step in and perform special processing on the incoming data", which is
> what I want, but it goes on to say, "However, because there's no way for
> modules to step in and actually contribute to the parsing of the HTTP
> header, this phase is more often  used just as a convenient place to do
> processing that must occur once per transaction."
> 
> Is this last sentence not the negation that I read it to be?  It seems to
> me that it is telling me that I really can't write a handler to actually
> do something useful on the incoming request header.

The key phrase there is "contribute to the parsing of the HTTP header".
You can manipulate the header after it's parsed (with stuff like
$r->headers_in), you just can't take over Apache's built in parsing of
the raw header data into the request record.

Since you're not actually taking over the business of translating the
URI into a filename, it really doesn't matter if you install your
handler as a PostReadRequestHandler or a TransHandler - you just want to
step in and take action before the request gets too far along.  It won't
_interfere_ with the translation phase as long as you make sure to
return DECLINED instead of OK so that other configured handlers (or the
defaults) can run.

-- 
Kevin  | "It's Supposed To Be Automatic, But     
Murphy |  Actually You Have to Push This Button" 
       |  - John Brunner, "Stand on Zanzibar"

Re: which handler?!?

[Doug MacEachern <do...@covalent.net>]

On Wed, 5 Apr 2000, J. Horner wrote:

> I'm finally writing the web server intrusion system that I've planned for
> months.  I have the skeleton for the URI comparing handler, but I'm a
> little unclear where it should really go.
> 
> A handler is written to compare the URI against a source of known web
> server issues to alert the administrator to hacking attempts.  Should the
> handler be installed at the PerlPostReadRequestHandler phase or the
> PerlTransHandler phase.  The Eagle book says something like:
> 
> "It is called once per transaction and is intended to allow modules to
> step in and perform special processing on the incoming data", which is
> what I want, but it goes on to say, "However, because there's no way for
> modules to step in and actually contribute to the parsing of the HTTP
> header, this phase is more often  used just as a convenient place to do
> processing that must occur once per transaction."  
> 
> Is this last sentence not the negation that I read it to be?  It seems to
> me that it is telling me that I really can't write a handler to actually
> do something useful on the incoming request header.  

keyword is `parsing', once the HTTP request is parsed, you can modify the
$r->headers_in table in any phase.
 
> If I put the hander in at PerlTransHandler, it seems that I would
> interfere unnecessarily at the translation phase.  I just want a place to
> put it where it can take the request, run a regexp against a list of known
> issues to check for a match, then, if we return a false, go on with the
> parsing and file mapping.

you won't interfere if you return DECLINED from a PerlTransHandler.