Version Differences in IIS Web Application Features

This topic describes important differences in IIS Web application development technologies between IIS 4.0, IIS 5.0, IIS 5.1, and IIS 6.0.

One of the most important changes in IIS 6.0 addresses Web server security. In order to take a more proactive stance against malicious users and attackers, IIS is not installed on members of the Microsoft Windows Server 2003 family by default.

For more information about IIS 6.0 security, see "Security" in IIS Help, which is accessible from IIS Manager or from Internet Information Services 6.0 Product Documentation.

When you initially install IIS 6.0, the service is installed in a highly secure and "locked" mode. By default, IIS serves only static content. This means that features like ASP, ASP.NET, Server-Side Includes, WebDAV publishing, and FrontPage Server Extensions do not work. You can serve dynamic content and "unlock" these features through the Web Service Extensions node in IIS Manager, or by using the iisext.vbs command-line tool. For more information about the initial state of IIS, see "Enabling and Disabling Dynamic Content" in IIS Help, which is accessible from IIS Manager.

In This Topic

This topic includes information on the following:

• Core Functionality and Services

• Active Server Pages (ASP)

• ASP Hang Detection

• Security

• IIS Utility Components

• ISAPI Extensions

• ISAPI Filters

• IIS on 64-bit Microsoft Windows Server 2003

Summary

The following table summarizes the important differences between versions of IIS.

to top

Core Functionality and Services

• IIS 6.0 has been redesigned to take advantage of the base Windows kernel, HTTP.sys. This allows for built-in response and request caching and queueing, and the ability to route application process requests directly to the worker processes, improving reliability and performance.

• IIS 6.0 introduces two modes of operation in order to configure your application environments: IIS 5.0 isolation mode and worker process isolation mode.

• IIS 6.0 is built in unicode. If you have an application that utilizes ANSI processes, it will fail in IIS 6 Worker Process Isolation Mode because MFC.DLL is ANSI and it is compiled to use the __argv global. The IIS W3WP.exe process is built in unicode and it is compiled to use the __wargv parameter.

to top

IIS 5.0 Isolation Mode

IIS 5.0 isolation mode manages application processes in a similar fashion to the process management in IIS 5.0: all in-process applications run inside Inetinfo.exe, and out-of-process applications run in separate DLL hosts. Some existing applications may not have been written to run concurrently, or store state separately from the application. Therefore, running processes in IIS 5.0 isolation mode ensures compatibility for most existing applications.

The following illustration shows how application processes are handled in IIS 5.0 isolation mode.

to top

Worker Process Isolation Mode

When configured to execute in worker process isolation mode, all application code runs in an isolated environment. This design removes some of the existing bottlenecks. Worker process isolation mode allows the administrator to isolate anything from an individual Web application to multiple sites in their own self-contained World Wide Web Publishing Service (WWW service) process. This prevents one application or site from stopping another. In addition, separating applications or sites into their own process space simplifies a number of management tasks, such as restarts (independent of all other sites or applications running on the system), changing a component used by the application, debugging, monitoring counters, throttling resources, and so forth.

The following illustration shows how applications are managed by IIS in worker process isolation mode.

HTTP requests are routed to the correct application pool queue, which means that user mode worker processes serving a pool pull the requests directly from the kernel and eliminate the unnecessary process hops encountered when sending a request to an out-of-process DLL host. In IIS 6.0, there is no longer the notion of in-process applications; all necessary HTTP application runtime services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning HTTP application or Web site from disrupting other HTTP applications (or other Web sites) served from other processes on that computer. Unloading components becomes easier because with isolated application processes, the process can, if necessary, be terminated to unload all resources, with no effect on other content or applications being served from other processes. It is also beneficial to be able to leverage other operating system services available at the process level (for example CPU throttling), per application pool.

Furthermore, critical portions of worker process isolation mode that maintain the overall functioning of WWW services run entirely outside of the worker processes. The IIS 6.0 kernel-mode driver, HTTP.sys, which is the universal HTTP processor for Windows, and the WWW Service Administration and Monitoring component isolate the critical portions of the core Web server. Both of these components are protected and do not allow third-party code to be loaded into them. This design prevents a malfunctioning HTTP application from disrupting WWW services on the server.

For more information on isolation modes, see "IIS Isolation Modes" in IIS Help, which is accessible from IIS Manager.

to top

Active Server Pages (ASP)

• Beginning with IIS 6.0, ASP can be used along with ASP.NET. See ASP.NET for information on configuring IIS to run ASP.NET applications. Also see Important Changes in ASP for news on changes to ASP functionality in IIS 6.0.

• Beginning with IIS 6.0, IIS is built in unicode in order to provide improved support for international applications. This can affect features like Request.ClientCertificate Collection. If you are porting code from an older version of IIS, use custom COM object to convert the unicode data to ANSI in a return parameter that ASP can then display. For more information about creating COM objects for ASP pages, see Creating COM Components for ASP.

to top

ASP Hang Detection

When an IIS Web site is busy, there may be instances when the maximum number of ASP threads has been spawned and some of the ASP threads are unresponsive, resulting in degraded performance. IIS 6.0 has the ability to solve the problem of unresponsive threads by recycling the worker process that hosts that particular instance of the ASP ISAPI extension, ASP.dll. When ASP threads are unresponsive in IIS 6.0, ASP.dll calls the ISAPI server support function HSE_REQ_REPORT_UNHEALTHY, and the WWW service will recycle the worker process that hosts ASP.dll, and make an entry in the event log.

For more information on ISAPI Server Support Functions, see ServerSupportFunction in the IIS ISAPI Extensions.

to top

Security

One of the most important changes in IIS 6.0 addresses Web server security. See "Security" in IIS Help, which is accessible from IIS Manager. In order to take a more proactive stance against malicious users and attackers, IIS is no longer installed by default on Microsoft Windows Server 2003 family systems. Furthermore, when you initially install IIS, it is installed in a highly secure and "locked" mode.

By default, IIS serves only static content, which means that features like ASP, ASP.NET, Server-Side Includes, WebDAV publishing, and FrontPage Server Extensions do not work. You can serve dynamic content and "unlock" these features through the Web Service Extensions node in IIS Manager, or by using the iisext.vbs command-line tool. For more information about the initial state of IIS, see "Enabling and Disabling Dynamic Content" in IIS Help, which is accessible from IIS Manager.

Many of the security features available in IIS 4.0 have been simplified in IIS 5.0, 5.1 and IIS6.0, which have new security task wizards: the Permissions Wizard, the Web Server Certificate Wizard, and the CTL Wizard. With these three wizards, you can synchronize Web and NTFS security settings, obtain and install server certificates, and create and modify certificate trust lists. In IIS 5.1 and IIS 6.0, you can select a cryptographic service provider (CSP) for encrypting data with a certificate. For more information, see see "Using the New Security Task Wizards" in IIS Help, which is accessible from IIS Manager.

Other security changes in IIS 6.0:

• Index this resource is now enabled by default.

• Script source access, which allows access to the source code of scripts in ASP pages and other scripts, is new and is disabled by default. It is available only if either Read or Write permission is selected.

• Sub-authentication is no longer enabled by default on a new installation of IIS 6.0. For more information, see AnonymousPasswordSync.

• FrontPage Web, which allows administration of sites on your server by using FrontPage, is no longer set in IIS Manager. It is enabled by default.

• Fortezza support has been removed.

For more information about IIS security, see INFO: Security Ramifications for IIS Applications.

to top

IIS Utility Components

• Collaboration Data Objects for Windows? NT? Server (CDONTS) have been removed from the Windows Server 2003 family. If your Web applications use CDONTS, you can convert them to Microsoft Collaboration Data Objects (CDO). Most methods in CDONTS have matching methods in CDO, but might be named differently. You can find reference material for CDO in the Platform Software Developer Kit, or at MSDN Online under Overview of CDO.

• The IIS utility components (Ad Rotator, Browser Capabilities, Content Linker, Content Rotator, Counters, Logging Utility, My Info, Page Counter, Status, Tools) are not installed with IIS 6.0. However, if you upgrade your Web server from a previous version of IIS, the utility components are not removed. You can obtain copies of the utility component DLL files from the IIS 6.0 Resource Kit.

to top

ISAPI Extensions

The following changes or new features are available to ISAPI extensions in IIS 6.0 and are defined in the ISAPI reference section:

• ISAPI Extensions Disabled by Default: All ISAPI Extensions (including ASP, ASP.NET and other methods of producing dynamic content) are disabled by default so that IIS 6.0 is installed in a highly secure state. To configure your server to enable ISAPI extensions, open the IIS Manager and click the Web Service Extensions node.

• Unicode Server Variables: New unicode versions of existing server variables are available to ISAPI extensions in IIS 6.0. They are accessed by prepending UNICODE_ to an existing ANSI server variable, for example, UNICODE_REMOTE_USER, UNICODE_URL, UNICODE_PATH_INFO.

• GetServerVariable Server Support Function: ISAPI extensions can now use the "HEADER_" prefix to access any header, including those that contain dashes in their names. Using the "HTTP_" prefix is still supported.

• Unicode Versions of selected Server Support Functions: HSE_REQ_MAP_UNICODE_URL_TO_PATH, HSE_REQ_MAP_UNICODE_URL_TO_PATH_EX, and HSE_REQ_EXEC_UNICODE_URL have been added to IIS 6.0 which take extra parameters that are expected in unicode programming.

• Wildcard Application Mappings: This feature is an improvement of existing IIS functionality. A wildcard application mapping maps an ISAPI extensions to an entire application, running the ISAPI extension regardless of the file name extension of the requested file. Wildcard application mappings are an ordered chain of ISAPI extensions which cooperate by using HSE_REQ_EXEC_URL to enable multiple executables to sequentially process a given request.

• ISAPI Extension ServerSupportFunction: In IIS 6.0, the following parameter names of the ISAPI extension ServerSupportFunction were added or changed:

  • HSE_REQ_GET_EXECUTE_FLAGS has been changed to HSE_REQ_GET_EXEC_URL_STATUS

  • HSE_REQ_EXECUTE_CHILD has been changed to HSE_REQ_EXEC_URL

  • HSE_REQ_IS_IN_PROCESS, HSE_REQ_REPORT_UNHEALTHY, HSE_REQ_REPORT_UNHEALTHY, HSE_REQ_VECTOR_SEND, and HSE_REQ_SEND_CUSTOM_ERROR are all new features to IIS 6.0.

  • HSE_REQ_NORMALIZE_URL has been added which mirrors the existing ISAPI Filter ServerSupportFunction SF_REQ_NORMALIZE_URL. Primarily, HSE_REQ_NORMALIZE_URL is used with HSE_REQ_EXEC_URL to allow ISAPI Extensions to protect themselves from malicious URL canonicalization attacks.

• New Server Variable: A new server variable called SCRIPT_TRANSLATED can be called from ISAPI extensions in IIS 6.0.

to top

ISAPI Filters

The following changes or new features are available to ISAPI filters in IIS 6.0 and are defined in the ISAPI reference section:

• FilterEnableCache: A new metabase property called FilterEnableCache can be set on individual filters to mark them "cache friendly" to HTTP.sys. This means that the filter does not conditionally reroute URLs for /default.htm to either /default-1.htm or /default-2.htm which would break the HTTP.sys cache. By default, filters are considered unfriendly to the HTTP.sys cache.

• Filter Load/Unload Order in the Isolation Modes of IIS 6.0: In IIS 5.0 Isolation Mode, filter load order is the same as for IIS 5.0 in that global filters load when the IIS services start, site filters load automatically when added, and all filter DLLs are unloaded when W3SVC.exe is stopped. In Worker Process Isolation Mode, a global filter loads in all W3WP.exe worker processes while a site filter loads in the W3WP.exe processes belonging to the application pool servicing the site. No filter DLL is loaded into memory until a request is made to a site which starts the W3WP.exe process, or when the W3WP.exe process is recycled. Until then, all filters contained in a site are unloaded. Thus, filters are not guaranteed to be singletons nor guaranteed to be in memory for the lifetime of IIS being running. This means that a site filter is not loaded into memory until the Web site where it is installed has handled at least one request. In IIS 5.0 isolation mode, a filter is loaded as soon as it is installed.

• A Change to AddResponseHeader: Headers that are set with this function are sent in all responses after they are set. In IIS 5.0, these headers were not sent in certain 401 responses.

• HTTP Error 400 Requests: HTTP error 400 requests that cause HTTP.sys to reject them will not trigger a filter event notification. The only exceptions are ISAPI Filters that register for ReadRawData notifications.

• ReadRawData Notifications: These notification are only allowed in IIS 5.0 Isolation Mode and are explicitly disallowed in Worker Process Mode. IIS does not load filters registering for ReadRawData notifications while in Worker Process mode.

• Unicode Server Variables: New unicode versions of existing server variables are available to ISAPI Filters. They are named by prepending an existing server variable name with "UNICODE_".

• Process Identity: If the IIS server is running in worker process isolation mode on IIS 6.0, the process identity is a member of the IIS_WPG group because filters run in the W3wp.exe process (also called the worker process for the application pool). For more information, see IIS Application Identities.

to top

IIS on 64-bit Microsoft Windows Server 2003

On the 64-bit Windows Server 2003 family of operating systems, IIS runs as a 64-bit application. This means that 32-bit applications cannot be called from IIS on 64-bit Windows Server 2003 servers. For example, the Jet database engine will not convert to a 64-bit application, so you cannot use ADO to open an Access database from an ASP page. However, you can still use ADO to access other drivers like SQL and Exchange.

See Also

Concepts

Version Differences in IIS Administration Features