HOWTO: Make XSLISAPI2.DLL work on IIS 6.0


This is an “in-progress” blog entry where I document the steps necessary to get XSLISAPI2.DLL to work on IIS 6.0. This has been requested several times on the microsoft.public.inetserver.iis and microsoft.public.platformsdk.internet.server.isapi-dev newsgroups, so I decided to do a little investigation on what is going on with this ISAPI and IIS 6.0 and have a running documentary of the investigation.

Since the source code of the filter is completely given in the download (you can download and compile yourself), I presume it is user-supported.

If you’d permit me a moment for a side-comment — notice how openly available source does not always work out — even though the source code is openly available and there has been several itches that people have wanted to scratch, without the motivated people to SUPPORT the source code, the concept will not make it.

Ok, digression aside, let us look at what is going on within this ISAPI Filter and how to make it work on IIS 6.0


I have only read through about 30% of the ISAPI Filter source code, and I can say that this ISAPI Filter has several flaws in it, some of which are exposed by IIS 6.0, and they prevent it from functioning. The issues (and resolution) are:

  1. In IISFilter.cpp::CheckVFileForSSL() , the filter incorrectly assumes that the AccessSSLFlags property is set for any given URL and then fails if it is not. This is simply not a valid assumption and can cause custom error behavior on IIS to be strange.
  2. Notice that the filter affects 404 responses when the URL extension is not 3 or 4 characters. Try /pagerror.gif , /pagerror.gif1 , and /pagerror.gif12 and you will notice the difference.
  3. The Filter tries to determine the file extension of the URL in SF_NOTIFY_PREPROC_HEADERS, which is completely wrong. It is simply not possible, especially if there is another ISAPI Filter that changes the URL. One can come up with a legitimate ISAPI Filter which will break this filter, and there is no band-aid fix for this flaw.
  4. Global.h::g_szSourceFile is set to “SSXSLSRCFILE:” and is subsequently used in two places, IISFilter.cpp::LogFilterEvent() and IISFilter.cpp::HttpFilterProc() . However, the code is incorrect in IISFilter.cpp::LogFilterEvent() and takes advantage of an IIS5 bug (fixed in IIS6). Namely, “HTTP_SSXSLSRCFILE:” is not a valid request header name for a call to HTTP_FILTER_CONTEXT::GetServerVariable(). It needs to be “HTTP_SSXSLSRCFILE” (without the “:”). The quick fix, of course, is to introduce a g_szSourceFile2 variable alongside g_szSourceFile, without the trailing “:”, and use it ONLY in IISFilter.cpp::LogFilterEvent()
  5. <TBD> as people help iterate through any remaining issues from IIS by providing me comments on what is/not working, what configuration is necessary, and any sample files to reproduce the issue. I do not know what XSLISAPI2.DLL is supposed to do; I can only help on the ISAPI Filter portion.

Work-around Steps

  1. Download xslisapi.exe from:
  2. Extract the files to anywhere that is not web-accessible
  3. Edit Global.h to include:
    const char g_szSourceFile2[] = “SSXSLSRCFILE”;
  4. Edit IISFilter.cpp::LogFilterEvent() to use g_szSourceFile2 instead of g_szSourceFile.
    *** Important: Leave the one in IISFilter::HttpFilterProc() alone. It is correct ***
    char szSrcFileEnvVariable[6 + sizeof(g_szSourceFile2)];

  5. If you do NOT have SSL set up, use the following (where ### is the ID of your website):
    CSCRIPT %SYSTEMDRIVE%\Inetpub\adminscripts\adsutil.vbs SET W3SVC/###/ROOT/AccessSSLFlags 0
  6. <TBD> For remaining issues.


Comments (6)

  1. Trey Schultz says:

    XSLISAPI2.DLL is a portion of Microsoft’s "Reference Architecture for Commerce". The system is also described as the "prescriptive architecture". It’s similar to what I’ve heard about Ruby. The ISAPI filter traps a request for a page with the .pasp extension. This file will contain ASP code (old VB ASP, ick). The code writes out an XML file. The XML output is then sent to an xsl stylesheet with the same base filename. The xsl generates HTML, and the filter sends this phantom HTML doc to the client. It’s meant to be an ultimate separation of function and presentation. It’s horribly difficult to debug and maintain in more than a black box fashion.

    I’m currently charged with upgrading a site from win 2k and cs 2k to win 2k3 and cs2k2. I’m hoping your revelations on this filter will help. Perhaps my pointers as to the filter’s intent will help your investigation.


    Trey Schultz


  2. David.Wang says:

    Thanks Trey for the context. I have never implemented nor supported any solution using XSLISAPI2.DLL, so I really have no idea what it all looks like. :-/

    I basically come to the issue from the perspective of IIS and ISAPI Filter behavior as I can deduce by reading the source code of XSLISAPI2.DLL.

    If you still require more work-around steps to have the XSLISAPI2.DLL portion of the solution working, please feel free to give me some more context/sample files that illustrate the issue. For example, I have yet to see what a sample .pasp nor .xsl file look like, nor of the settings on the rest of the website.


  3. turin says:

    This doesn’t even work

    can’t add a simple wildcard application map

  4. David.Wang says:

    I am not certain what you mean by "this does not even work". XSLISAPI2.DLL is an ISAPI Filter and needs to be configured as such. You literally cannot configure it as a wildcard scriptmap because it is not the right type of DLL.

    Can you please clarify what you are actually trying to do?


  5. buzzrick says:

    I’m sorry to drag up a 2 year old thread, but i’m trying to figure out why I can’t get access to the querystring when using XSLISAPI on IIS6.  I can access all of the Request.ServerVariables items except Request.ServerVariables("QUERY_STRING"), which shows as blank from within my asp code.

    Also, I can access all of my Request.Form items, but I can’t see any Request.QueryString items.

    I’ve compared results between a Win2000 server and a Win2003 server and the querystring is the only thing that I can’t access when I’m using XSLISAPI.

  6. buzzrick says:

    I’ve investigated this further, and it appears that calling the SF_REQ_NORMALIZE_URL ServerSupportFunction seems to strip the query string out.

    I’m still trying to figure a solution around this.