There's a great tutorial on the MSDN magazine website
You should be able to follow through the above article and then read through the further reading down the bottom and it should help you to userstand what ISAPI filters are and how they work.
Edit: looks like the further reading is defunct (thanks microsoft). So I've done a little more research and found 2 more article with code examles. One of which is actually logging usernames from request cookies (code project).
If you've reached this point, chances are you want the general
solution, one that maps any arbitrary URL to your implementation ASP
or ASPX files without the limitation of the file extension I've
discussed. The only way I know to do this is outside the .NET
Framework, using plain old ISAPI filters. You see, ISAPI filters are
HTTP handlers native to IIS and they are given a chance to run very
early, before any framework code in ASP.NET.
Conceptually, ISAPI filters are very similar to the ASP.NET
HTTPModules I discussed earlier. A major difference is that ISAPI
filters must be written in C or C++. There is plenty of literature on
ISAPI filters so I will only touch on them briefly here (see ISAPI,
and Tips and Tricks for ISAPI Programming for more information).
In practice, an ISAPI filter is a Windows DLL that provides the
following two entry points:
DWORD WINAPI HttpFilterProc(
DWORD notificationType, LPVOID pvNotification
BOOL WINAPI GetFilterVersion(
The IIS runtime calls the GetFilterVersion method when the filter is
initialized. The filter should use this opportunity to notify IIS
about the events it cares about. Then, when HTTP requests arrive, IIS
calls the HttpFilterProc once for every event for which the filter
asked to be notified. If you want to make things a little bit easier
you can use the MFC class CHttpFilter, which conveniently wraps the
raw C API and routes the events to one or more virtual methods that
you implement. The rest of the discussion will assume that you use the
MFC-provided wrapper (see Writing Interactive Web Apps is a Piece of
Cake with the New ISAPI Classes in MFC 4.1).
Figure 6 shows the C++ code that rewrites the URL and stores
part of the virtual path in a pseudoheader. The event that you need to
catch in order to rewrite the URL is OnPreprocHeaders. The trick here
is that you can use the special header URL to read the original URL.
Then, after rewriting the URL, you can use the SetHeader call to set
the special header URL, forcing IIS to call your file. The code shown
in Figure 6 changes a URL like /bestpayroll/msdnmag/ report2 to
/bestpayroll/report2.aspx. Notice how the company name has been
removed and the .aspx suffix has been added. Most of the ugly code
deals with extracting the company name and then piecing together the
rest of the URL for the request.
The last remaining task is to communicate either the original
URL or the company name to the ASP.NET form. There is no clean way to
communicate from an ISAPI filter to either ASP or ASP.NET. What I can
do is add a new header. A header called companyname can be read from
ASP.NET using the Request.ServerVariables collections, as shown here:
<form id="test" method="post" runat="server">
The company is
Here I hardcoded the logic that rewrites URLs into the C++ code. In
more realistic scenarios the logic should reside in a configuration
file that is parsed by the filter during initialization.
Perhaps better code examples of ISAPI Filters with a clearer explanation