IIS HttpModule修改请求体不生效原因及适配非aspx端点方法

限定.aspx后缀、仅x-www-form-urlencoded生效的本质原因 #

• 管道路由的模式差异：.NET Framework经典托管管道模式下，请求按扩展名映射到对应处理器工厂：.aspx、.ashx这类显式注册的扩展名，会走完整System.Web管道流程，自定义RequestFilter的挂载逻辑会被下游处理器读取；无扩展名的REST端点（如WebAPI、MVC无后缀路由）在经典模式下甚至不会映射到托管管道，HttpModule内的Filter替换逻辑根本不会被下游组件感知，自然无法生效。
• 内置表单解析的触发条件限制：ASP.NET原生HttpRequest.Form属性的内置逻辑仅针对application/x-www-form-urlencoded格式解析：调用该属性时，解析器会先校验Content-Type，匹配的情况下才会主动读取全部请求流完成键值对解析，此时才会触发替换后的自定义RequestFilter的处理逻辑；如果Content-Type不匹配，解析器直接返回空集合，完全跳过流读取步骤。之前添加var _ = context.Request.Form;代码仅对表单请求生效，本质就是该校验逻辑在起作用——json、xml、纯文本类型的请求调用该属性时，根本不会触发流读取，自定义Filter逻辑没有执行机会。
• 流指针与缓存的冲突：HttpModule阶段读取原始请求体时，会将请求流的位置指针推到流末尾；如果未重置指针、也未将修改后的内容写回Filter流，下游组件就算读取流，也会拿到指针位置之后的空内容，或直接命中管道提前缓存的原始请求体内容——这就是日志显示HttpModule已将请求体处理为大写，但API返回原始小写内容的核心原因。

非.aspx端点、多Content-Type请求的适配方案 #

• 切换应用程序池托管管道模式为集成模式：该模式下所有进入应用的请求（无论后缀类型）都会完整走全局管道事件，在BeginRequest/AuthorizeRequest阶段挂载自定义RequestFilter的逻辑，会对所有请求生效，不再受.aspx扩展名的路由映射限制。
• 不依赖内置Request.Form属性触发流处理：对所有带请求体的请求，挂载好自定义Filter后，手动将原请求流位置重置为0（Request.InputStream.Position = 0），主动通过替换后的Filter流读取全部请求内容，完成大小写转换、键值对追加等自定义处理后，再将Filter流位置重置为0，保证下游控制器、转发代理可以从头读取修改后的内容。
• 自定义RequestFilter去掉内置表单的格式判断逻辑：不要将过滤逻辑绑定在x-www-form-urlencoded格式上，无论json、xml还是纯文本请求，只要存在非空请求体，就按预设规则完成内容修改，避免被内置Content-Type校验逻辑卡住。
• 校验流传递链路：集成模式下确保所有下游组件（包括WebAPI格式化器、转发到第三方API的HttpClient实例）直接从Request.Filter指代的流读取内容，而非从管道缓存的原始请求体字段取内容，避免修改后的内容被原始缓存覆盖。

内容的提问来源于stack exchange，提问作者Jesper Lundin