Subject: From: Date:

Re: [ECS] CGI/ISAPI help ? Dave Kolb Thu, 3 Jun 1999 20:46:47 -0400

---

Mark,

A few things to note and check:

1. You can have a filter and/or a Internet Server Application (ISA). The
later is the counterpart to the CGI script as opposed to the filter.

2. If you want a ISA that calls an in process DLL (much faster) rather than
an out of process EXE or BAT (much slower), you use a URL that says
something like http://script/myisa.dll?params rather than
http://script/mycgi.exe?params

3. All DLLs written as Internet Web Server applications are required to
export two entry points: GetExtensionVersion and HttpExtensionProc
(TerminateExtension is optional). Also you communicate through an
EXTENSION_CONTROL_BLOCK which imo is more convenient.

4. If you really want a filter that gets called on ALL http traffic then you
need to add the filter's DLL name to HKEY_LOCAL_MACHINE\ System\
CurrentControlSet\ Services\ W3Svc\ Parameters\ Filter DLLs." This is a
comma-separated list and the filter should be added to the end of the list.
Every filter is contained in a separate DLL with two common entry points:
GetFilterVersion and HttpFilterProc.

Here's some more details:

When the server starts up, it reads the values and loads the DLLs listed. It
then calls the GetFilterVersion entry point to exchange version information
and determine the requested notifications and the order in which to deliver
them. As events occur, the server will notify each filter application
registered for an event in the priority order requested by GetFilterVersion.
This is accomplished by calling the HttpFilterProc entry point. In the event
of a tie, the order listed in the registry is used.

When the GetFilterVersion entry point is called, an HTTP_FILTER_VERSION
structure is presented which must be filled out with the version
information, the requested events, and a priority level. ISAPI filter
applications should register only for the events that are immediately
required, because registering for unnecessary events can have a significant,
negative impact on performance and scalability.

After this first exchange, every time the server processes one of the
available events, it will call any filters that have been registered for
that event. The order in which the server calls the filters depends first on
the priority specified in the dwFlags member of HTTP_FILTER_VERSION by
GetFilterVersion. In the event that two or more different filters have
registered for the same event at the same priority, the order that the
filters were loaded from the registry determines the order in which they
will be called.

When the HttpFilterProc entry point is called, the filter will typically
perform a switch on the notificationType parameter to determine what action
to take. For example, an encryption or compression filter will probably
register for reading and writing raw data, while a logging filter will
probably only register for the log event. Most filters will also register
for the end of the net session event. This event is an opportune time to
recycle any buffers used by that client request.

For performance reasons, most filters usually keep a pool of filter buffers
and only allocate or free them when the pool becomes empty or too large to
save on the overhead of the memory management. One useful callback is the
AllocMem callback in the HTTP_FILTER_CONTEXT structure. This allocates
memory that is automatically freed when the communication with the client is
terminated. As noted, this can have a negative impact on performance, but
with careful use it can be a valuable to

The HTTP_FILTER_CONTEXT structure is passed to the HttpFilterProc and is the
structure used to get the data from and where to make callbacks.

Dave Kolb
Personal Systems

---