IIS 4.0 introduced significant changes to the ways you can develop and implement Internet applications. This section describes the changes that affect how you develop ISAPI extensions.
In IIS 3.0 and earlier, 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.
In IIS version 4.0 and later, you can 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.
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 metabase property InProcessIsapiApps to specify all ISAPI DLLs that you want to run in the same server process as IIS. 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.
Caution A software error in ISAPI DLLs will stop the 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 must run in the same process as IIS.
For more information on using the metabase, see Administering IIS Programmatically.
Many new server variables that can be specified by the GetServerVariable function have been added.
Three new requests for ServerSupportFunction have been added. They are:
HSE_REQ_SEND_RESPONSE_HEADER_EX
HSE_REQ_GET_CERT_INFO_EX
HSE_REQ_GET_IMPERSONATION_TOKEN
IIS 4.0 introduced 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 supports 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 chunks of varying sizes. Each chunk contains its own size indicator and optional footers for specifying header fields. Chunking, in and of itself, is potentially less efficient than non-chunked connections, although it is impossible to suffer significant overhead from the additional transport layer headers required for multiple chunks. Chunking is more efficient in terms of internal, application processing, however, especially for streaming data sources, or very large data sets.
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.