SharePoint Managed Path and IIS ISAPI

In SharePoint 3.0 there is no more extra ISAPI extension such as the one in WSS 2.0. All requests are routed to aspnet_isapi.dll instead.

The aspnet_isapi.dll will serve a request if a physical IIS path is found as a match. For example, in IIS you can create a subfolder out of root directory of sharepoint site, and you can browse files inside the subfolder. Doing this actually blocks this subfolder name as sharepoint managed path, since IIS handle requests first.

If no physical IIS path found, Http handlers and Http Modules which are defined in the web.config will start to knick off to handle http requests. At this point, the managed path info will be used to resolve URL.

Update 04/05/2010: IIS will do authentication,and after that the request is yielded to the SharePoint14Module, which will contact file system first and then content database for appropriate page. See this blog for details.

There is an exception: if you put files (other than folders) under iis root directory of sharpoint site, those files can not be served unless they are defined as Explicit Inclusion type of managed path. This seems to be the wss 2.0 "excluded" concept.

Update: this exception only applies to MOSS and WSS 3.0, it is fixed in SharePoint 2010. great fix, no more confusing.