为何ASP.NET Core Web API在IIS下用管道仍需EnableBuffering？管道价值探讨

背景说明 #

我们需要在端点的授权处理程序中从请求体提取值以判断用户是否授权，同时该请求体还需被端点本身重新读取。最初采用以下管道方式实现：

var pipeReader = httpContext.Request.BodyReader;
var result = await pipeReader.ReadAsync(httpContext.RequestAborted);
var buffer = result.Buffer;

// 标记未消费任何数据，让端点可以重新读取请求体
pipeReader.AdvanceTo(buffer.Start, buffer.End);

// 处理buffer提取所需信息的代码

该代码在Kestrel环境（Visual Studio 2022沙箱或直接运行）下完全正常，但在IIS（含IIS Express）环境下，必须启用缓冲并重置请求体位置，否则会返回400状态码及"A non-empty request body is required."错误，需调整为：

var request = httpContext.Request;
request.EnableBuffering();
var pipeReader = request.BodyReader;
var result = await pipeReader.ReadAsync(httpContext.RequestAborted);
var buffer = result.Buffer;

// 标记未消费任何数据，让端点可以重新读取请求体
pipeReader.AdvanceTo(buffer.Start, buffer.End);

// 重置位置以允许重新读取请求体
request.Body.Position = 0;

// 处理buffer提取所需信息的代码

问题1：为何该代码在Kestrel下正常，而以IIS作为反向代理时却不行？ #

核心原因在于Kestrel与IIS反向代理的请求体处理机制差异：

• Kestrel环境：BodyReader的设计原生支持"未消费标记"操作。当调用AdvanceTo(buffer.Start, buffer.End)时，Kestrel的管道会完整保留读取到的缓冲数据，后续读取请求体的组件（比如端点的模型绑定）可以从原始起始位置重新读取，不会认为请求体已被耗尽。
• IIS反向代理环境：ASP.NET Core通过AspNetCoreModule接收请求体，该模块的请求体流转逻辑不支持这种"未消费保留"操作。一旦通过BodyReader读取了数据，即使标记未消费，模块也不会保留缓冲，后续尝试读取时会返回空请求体，触发模型绑定的非空校验错误。同时，IIS环境下默认的请求体流不支持 seek 操作（CanSeek为false），必须通过EnableBuffering()将请求体缓存到内存或磁盘，让流变为可重读，再重置Position=0才能让后续组件从头读取。

问题2：这种情况下使用管道是否还有意义？ #

依然有显著意义，PipeReader的流式处理优势并未因适配IIS环境的步骤而消失：

• 内存效率更高：即使启用了缓冲，PipeReader允许你在读取过程中逐段解析授权信息，不需要将整个请求体完整加载到内存。对于大请求体场景，能有效减少内存占用，避免直接读取整个请求体带来的内存压力。
• 异步性能更优：PipeReader基于管道的异步通知模型，比直接操作Stream的异步方法更适合高并发场景，能减少线程阻塞，提升整体处理效率。
• 代码可复用性：核心的请求体解析逻辑可以在Kestrel和IIS环境下复用，仅需在IIS环境下添加EnableBuffering()和位置重置的适配代码，无需重构整个处理逻辑。

综上，虽然需要额外的缓冲启用步骤，但PipeReader带来的流式处理收益依然存在，相比传统的完整读取请求体方式更具优势。

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