I would like to see an API developed that would let
modules attach data and metadata to specific connections.
Such an API would make it easier for modules to perform
work at various times in a connection's life: init,
request processing, logging, and conn tear down.
This API would also make it much easier for modules to
cooperate and delegate tasks amongst themselves.
An example (from 3.x)
Access logging is performed by the nslog module. Right
now, on several of my servers, there are a bunch of
metarequests that are made. Uptime monitoring,
ns_telemetry requests, etc. There are also useless
requests caused by Code Red etc. For a variety of
reasons, I choose not to even log these requests. I do
this by creating a input request filter. When that
filter recognizes a virus, or metarequests, it knows to
flag the connection in such a way as to inform the log
module not to log the request. There is no connection
specific method for doing so at this time, so what I do
do is set an X-Log False header in the connection's
Input Header Set. This is a complete and ugly kluge.
But it does work, and when the nslog module comes
along, it sees the input header and checks for X-Log
False. If it finds it, it returns.
Recently there was discussion of creating a mechanism
that would recognize requests that come from search
engines, and that would alter the output stream to
highlight the search engine keywords. One way of
approaching this task is with two modules. One, on
accepting a request, examines the referrer field and
noting it comes from a search engine, it proceeds to
annotate the connection with the specific words or
phrases to be highlighted. Then, as output is created,
another module can recognize the connection specific
keywords and alter the output stream accordingly.
The value of breaking this into two modules as
described is it that it separates the highlight
processing from the request processing. This would
make it easier to highlight requests from external
search engines, or from internal site queries.
The key requirements of this API are to:
a) provide connection specific storage
b) provide an API to enable modules to cooperate in
sharing this connection specific storage. Presumably,
modules would want to hook or daisy chain individual
pieces of storage together.
c) provide well defined times for module specific
procedures to initialize and cleanup the connection