Information about the FilterEnableCache metabase property (824031)

MORE INFORMATION

When a particular URL can have more than one response, the Microsoft Internet Information Services (IIS) 6.0 response is known as a conditional response. Typical examples of conditional requests are the following:

• Requests that are made to ISAPI filters or to ISAPI extensions.
• Requests that must be authenticated.

The HTTP.sys kernel mode response cache compares the requested URL by using many parameters. These parameters include host name, port, SSL/HTTP, URI, PathInfo, and QueryString. If a URL is a match, HTTP.sys sends the cached response without making a transition to user mode. This enhances performance for the Web site.

If a URL is conditional and the only two possible responses are A and B, you can notify user mode code to conditionally send the version B response if HTTP.sys has only cached version A. In this situation, IIS in user mode must be notified on every kernel mode cache hit. This effectively means that for conditional requests, IIS may as well turn the kernel mode cache off. Wildcard application mapping currently turns off the kernel mode cache unconditionally, even if the response can otherwise be cached.

For more information about wildcard application mapping, visit the following Microsoft Web site: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx

For additional informationabout how to configure IIS to serve files with specific extensions or all extensions, click the following article number to view the article in the Microsoft Knowledge Base: By default, ISAPI filters and extensions are considered unfriendly to the HTTP.sys cache. For example, an ISAPI filter can take an incoming request for Default.htm and redirect it to Default1.htm or to Default2.htm, depending on how the ISAPI is set up to handle various client criteria.

When a request is processed, IIS can set the request as non-cacheable. IIS sets the request as non-cacheable when IIS must process the current URL in user mode. For example, IIS may have to set the following requests as non-cacheable:

• Requests to ISAPI extensions.
• Requests that must be authenticated.
• Requests that go through an ISAPI filter.

When you set the FilterEnableCache property for a particular ISAPI filter, you tell IIS not to set the non-cacheable flag for a request that goes through that ISAPI filter. Therefore, the particular response can still be cached in the kernel if no other process along the processing path sets the non-cacheable flag. This is typically useful if the filter only acts on specific content.

For example, two requests that can both be browsed anonymously go through the ASP.NET ISAPI filter. One request is to /Default.aspx, and the other request is to /Main.gif. If you do not set the FilterEnableCache property, the following behavior occurs:

• When the request for /Default.aspx goes through the ASP.NET ISAPI filter, the non-cacheable flag for the request is set. The response cannot be cached in kernel mode because the request is routed to an ISAPI extension.
• When the request for /Main.gif goes through the ASP.NET ISAPI filter, the non-cacheable flag for the request is also set. The response also cannot be cached in kernel mode. With this setting, no request that goes through the filter is cached in the kernel HTTP.sys cache.

If you set the FilterEnableCache flag for ASP.NET, the following behavior occurs:

• When the request for /Default.aspx goes through the ASP.NET ISAPI filter, the non-cacheable flag is not set because of the FilterEnableCache property. The response may still be cached in kernel mode. Because the request is routed to an ISAPI extension, IIS sets the non-cacheable flag. The Default.aspx response is not cached in kernel mode, and later requests for Default.aspx also go to user mode.
• When the request for /Main.gif goes through the ASP.NET ISAPI filter, the non-cacheable flag is not set because of the FilterEnableCache property. The response can still be cached in the kernel. The static file handler does not set the flag either, and /Main.gif is served from the kernel. Therefore, the resources to serve that file are reduced.