iis web core

IIS 的请求处理管道里，`IIS Web Core` 是那个真正干活的模块。它不像 `W3SVC` 那样负责监听端口、管理应用池，也不像 `WAS` 那样管配置和进程激活。`Web Core` 藏在更底层，直接跟 HTTP.sys 打交道，把内核模式递上来的请求拆开、解析、路由，再交给后续的模块去处理。

我第一次注意到它是在排查一个 500.19 错误的时候。错误信息里写着“配置错误：无法读取配置文件”，但文件权限明明没问题。用 Process Monitor 抓了一下，发现 `IIS Web Core` 在尝试读取 `applicationHost.config` 时被拒绝了。那一刻我才意识到，这个模块不只是处理请求，它还负责在运行时动态加载配置。每个请求进来，它都要根据 URL 去匹配站点、应用、虚拟目录，然后从配置系统里拉出对应的处理程序映射。这个过程是实时的，不是启动时一次性加载完就完事。

它的核心职责其实就三块：请求解析、配置解析、缓存管理。请求解析好理解，HTTP.sys 递过来的是原始字节流，`Web Core` 要把它变成结构化的 `IHttpContext`。配置解析稍微绕一点——IIS 的配置是分层的，`applicationHost.config` 管全局，`web.config` 管站点和应用，还有 machine.config 兜底。`Web Core` 要按顺序合并这些配置，遇到重复的节点还得处理覆盖关系。缓存管理最容易被忽略，但性能影响最大。URL 重写规则、MIME 类型映射、处理程序映射，这些查一次就够了，没必要每个请求都重新算。`Web Core` 内部维护了一个配置缓存，只有当配置文件被修改时才会失效重建。

有个细节挺有意思：`IIS Web Core` 处理 URL 的时候，会先做一次“规范化”。比如把 `%2e%2e` 解码成 `..`，把多余的反斜杠合并，把 `//` 变成 `/`。这一步是为了防止路径遍历攻击，但有时候也会带来意外。我见过一个案例，某个应用依赖 URL 里的双重斜杠来区分参数，结果被 `Web Core` 规范化之后全乱了。后来只能在 `web.config` 里加 `allowDoubleEscaping="true"` 才绕过。这说明它的行为不是完全透明的，你写的代码跟它解析出来的结果之间，隔着一层你看不见的转换。

另一个容易被忽略的点是 `Web Core` 和 `W3SVC` 的交互方式。`W3SVC` 是 Windows 服务，跑在用户模式，负责跟 HTTP.sys 通信。`Web Core` 其实是 `W3SVC` 加载的一个模块，但它处理请求的时候，很多时候是在内核模式完成的。这种混合模式带来一个后果：如果 `Web Core` 在解析配置时卡住了，整个请求会挂起，HTTP.sys 那边的超时计时器还在走。等超时了，客户端收到 503，但 `W3SVC` 的日志里可能什么都没有。排查这种问题得用 ETW 跟踪，看 `Microsoft-Windows-IIS-Configuration` 提供程序的事件。

说它重要，是因为几乎所有 IIS 扩展都建立在它之上。URL Rewrite 模块、Application Request Routing、甚至 ASP.NET Core Module，都要通过 `Web Core` 暴露的接口来注册自己的处理逻辑。它就像个交通枢纽，不直接决定请求去哪，但决定了请求能去哪。你改 `web.config` 里的 `` 节点，实际生效的就是 `Web Core` 在运行时重新计算处理程序映射表。改错了，请求就 404 或者 500，跟你的代码一点关系都没有。

想观察它的行为，最直接的办法是开 Failed Request Tracing。在 `web.config` 里配一条规则，把状态码 500 的请求全抓下来。生成的 XML 日志里会有一个 `GENERAL_REQUEST_START` 事件，后面跟着 `URL_CHANGED`、`CONFIG_RESOLVED` 之类的步骤。看多了就能摸清它的脾气：什么情况下会重新读配置，什么情况下直接用缓存，URL 被改了几次，最终交给哪个处理程序。这比看文档管用。