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.
