IIS 4.0 introduces significant changes to the ways you can develop and implement Internet applications. The changes that affect how you develop ISAPI applications and filters are summarized as follows.
In previous releases of IIS, you always ran ISAPI extensions in the same server process as IIS. While this allowed quicker performance, the danger that IIS would become corrupted if your extension did not handle errors properly was greater.
IIS 4.0 allows you to isolate an extension by running it in a separate server process. You can accomplish this by selecting the Run in separate memory space option in the IIS user interface when you create an extension. The configures the extension to map to the DLL which exposes the ISAPI extension entry points.
For more information on isolating applications, see Isolating Applications under Server Administration.
Some of your ISAPI extension DLLs may not be suitable for running in a separate server process. Issues that could prevent an ISAPI extension from running in a separate server process include:
You can use the administration property InProcessIsapiApps to specify all ISAPI DLLs that you want to run in the same server process as IIS. This property applies to a WebService. Requests for such ISAPI DLLs are routed to the default application root in IIS (/LM/W3SVC). The default application root is marked in-process only, which guarantees that all such requests will run in-process.
Warning: A software error in ISAPI DLLs will stop the IIS server. Therefore, unless you are sure that your DLL will never run out-of-process, do not add the DLL to this list.
Note Setup will create the InProcessIsapiApps property and populate it with Ssinc.dll and Httpodbc.dll, which only work if running in the same process as IIS.
For more information on using the metabase, see IIS Administration
IIS 4.0 introduces the metabase, a new data storage location. ISAPI filter information that you formerly stored in the System Registry should now be stored in the metabase. Metabase information can be modified either through the IIS Admin Objects or the IIS Admin Base Object.
Previously, you applied ISAPI filters across all levels of a server. There was no way to specify that a filter would only respond to events at a more granular level. In IIS 4.0, you can apply filters to all Web sites on a server or to a particular Web site only. A global filter will be notified of events that occur at any Web site on the server, while Web site filters are only notified of events at the site to which they are applied. You can specify both global and Web site filters with the user interface, or you can set the appropriate key values in the metabase. For more information on setting a filter see IIS Filter and IIS Filters in IIS Admin Objects.
TerminateFilter is a new entry point for ISAPI filters introduced in IIS 4.0. If your ISAPI filter exports TerminateFilter, it will be called when the filter is unloaded.
SF_NOTIFY_SEND_RESPONSE is a new notification that can be specified with the HttpFilterProc function.
Many new server variables that can be specified by the GetServerVariable function have been added.
Two new commands for ServerSupportFunction have been added. They are:
SF_REQ_DISABLE_NOTIFICATIONS
SF_REQ_GET_PROPERTY
In addition, three new options have been added to the ServerSupportFunction. They are:
HSE_REQ_SEND_RESPONSE_HEADER_EX
HSE_REQ_GET_CERT_INFO_EX
HSE_REQ_GET_IMPERSONATION_TOKEN
Three new members of the HTTP_FILTER_LOG structure have been added in IIS 4.0. They are:
IIS 4.0 introduces support for HTTP 1.1. Two areas where this has potential impact on ISAPI extension and filter developers is in support for pipelined requests and the transfer encoding header. Pipelined requests are described in Extension Request Processing.
Active Server Pages (ASP) now support the transfer encoding header, which tells the client if a transformation has been applied to the body of the message that is being sent. For example, if the client supports HTTP 1.1, IIS 4.0 can specify the Transfer-encoding value of chunked. When the chunked transformation has been applied, the message is broken into a chucks of varying sizes. Each chunk contains its own size indicator and optional footers for specifying header fields. Chunking improves the overall efficiency of the transmission.
For more information on Transfer encoding, see RFC 2068 published by the World Wide Web consortium. RFC 2068 is available at: http://www.w3.org/protocols. See Developer Samples for information on the sample extension that implements this technology.