C'è un ottimo tutorial sul sito web della rivista MSDN
Dovresti essere in grado di seguire l'articolo di cui sopra e poi leggere l'ulteriore lettura in basso e dovrebbe aiutarti a capire quali sono i filtri ISAPI e come funzionano.
Modifica : sembra che l'ulteriore lettura sia defunta (grazie microsoft). Così ho fatto un po 'più di ricerca e ho trovato altri 2 articoli con gli esami di codice. Uno dei quali è in realtà la registrazione di nomi utente dai cookie di richiesta (progetto di codice).
Estratto.
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(
PHTTP_FILTER_CONTEXT pfc,
DWORD notificationType, LPVOID pvNotification
);
BOOL WINAPI GetFilterVersion(
PHTTP_FILTER_VERSION pVer
);
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
<b><%=Request.ServerVariables["HTTP_COMPANYNAME"]%></b> </form>
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.
Esempi di codice forse migliori dei filtri ISAPI con una spiegazione più chiara