例 如，当传入针对 Info.asp 网页的请求时，IIS 会将此消息路由到 asp.dll ISAPI 扩展。然后，该 ISAPI 扩展将加载被请求的 ASP 页面，执行该页面，并将所呈现的 HTML 返回给 IIS，然后，IIS 将该 HTML 发送回请求客户端。对于 ASP.NET 页面，IIS 会将此消息路由到 aspnet_isapi.dll ISAPI 扩展。然后，aspnet_isapi.dll ISAPI 扩展将处理操作传递给托管的 ASP.NET 辅助进程，该辅助程序将处理请求，并返回 ASP.NET 网页的呈现 HTML。
您 可以自定义 IIS，以指定扩展名与 ISAPI 扩展的映射关系。图 1 显示了 Internet Information Services 管理工具的“应用程序配置”对话框。请注意，与 ASP.NET 有关的扩展名（.aspx、ascx、config、asmx、rem、cs、vb 及其他）均已映射到 aspnet_isapi.dll ISAPI 扩展。
以上是Scott Mitchell在文章中提到的，也就是说如果要实现ASP.NET下的重写，首先就要把程序处理路由到ISAPI中。这也就是我同事所想的，而我想的是路由到ISAPI后的，如果没有配置将HTML格式的文件也由ISAPI处理，则IIS就会自动处理HTML页面而不经过ISAPI则就返回页面不存在或其他的错误。这个和我们要控制HTML页面的访问权限也是一样的，如果我们要控制某个HTML页面适合一定的角色才能够访问，如果我们没有配置IIS也会直接访问而不会弹出没有权限的页面。
现在伪静态和URL到处可见，这也可能是适合搜索引擎的趋势，微软为了迎合市场的需要在IIS7.0中做了重大改进。达到这样的效果只要在Web.config配置文件中配置就可以了，而不要到IIS管理器中配置，这样也就可以让更多的用户在不需要管理权限下享受这一美好的午餐，下面是Scott Guthrie在博客中提到的。
ASP.NET和IIS 7.0之集成
在早期的IIS版本中，开发人员需要编写ISAPI 扩展/过滤器来扩展服务器的功能。除了写起来非常痛苦外，ISAPI在如何接入服务器以及允许开发人员定制方面也是非常有限。譬如，你无法在ISAPI扩 展中实现URL重写代码（注：ASP.NET是以ISAPI扩展的方式实现的）。假如你把运行时间长的代码编写成ISAPI过滤器的话，结果是你将占用 web服务器的I/O线程(这就是我们不让托管代码在请求的过滤器执行阶段运行的原因）。
我们在IIS7中对核心IIS处理引擎做的 一个重大的架构级变动是通过一个新的模块化的请求管道架构来促成极其丰富的扩展性。你现在可以通过与web服务器注册一个HTTP扩展性模块（HTTP Extensibility Module），在任意一个HTTP请求的生命周期的任何地方编写代码。这些扩展性模块可以使用native的C++代码或.NET托管代码来编写（你可 以使用现有的ASP.NET System.Web.IHttpModule接口来实现）。
所有“内置”的IIS7功能（认证，授权，静态文件供应,目录清单支持，经典的ASP，记录日志等），现在都是使用这个公开的模块化的管道API来实现的。这意味着你可以除去这些IIS7“内置”功能的任意一个，而以你自己的实现来替换/扩展这些功能。
从IIS6.0到IIS7.0可谓是一大进步，不仅组件化而且在功能上也有一大的进步。我们可以在这里看到Scott Mitchell的关于URL重写的文章：《在ASP.NET中执行URL重写》同时我们可以在ScottGu的中文博客中得到IIS7.0的介绍：《IIS 7.0》。
本文转自网魂小兵博客园博客，原文链接：http://www.cnblogs.com/xdotnet/archive/2007/07/23/url_rewrite_iis_6_7.html，如需转载请自行联系原作者
