.NET Core Web API中如何返回100 Continue HTTP状态码？

我之前也碰到过一模一样的问题！HTTP 100 Continue状态码的使用其实有严格的规范要求，不是随便赋值就能生效的，咱们来拆解一下问题所在：

先搞懂100状态码的正确使用场景 #

HTTP 100是专门为请求体较大的场景设计的：客户端先发送一个不带请求体的请求，同时带上Expect: 100-continue请求头，询问服务器“我准备发大请求体了，你准备好了吗？”。只有当服务器收到这个请求头后，返回100状态码才是符合规范的操作。如果客户端没发这个头，你硬要返回100，服务器会因为违反HTTP协议直接拒绝响应。

排查步骤和解决方法 #

• 检查客户端请求头
  先确认你的客户端是否在请求中包含了Expect: 100-continue头。如果没有，服务器是不会接受100响应的——这就好比你没问对方要不要接收，直接塞东西过去，对方肯定拒绝。

• 修正服务器端代码逻辑
  不能只单纯设置HttpContext.Response.StatusCode = 100;，还需要触发响应头部的发送，并且要先判断客户端的Expect头。以ASP.NET为例，正确的代码应该是这样：

  // 先判断客户端是否发送了Expect: 100-continue
  if (Request.Headers.TryGetValue("Expect", out var expectHeader) && 
      string.Equals(expectHeader, "100-continue", StringComparison.OrdinalIgnoreCase))
  {
      // 设置100状态码
      Response.StatusCode = 100;
      // 立即发送响应头部，告诉客户端可以发请求体了
      Response.Flush();
      
      // 接下来再处理请求体的接收逻辑
      var requestBody = await Request.BodyReader.ReadAsync();
      // ... 后续业务处理
  }
  

  关键是Response.Flush()——它会把已经生成的响应头部（包含100状态码）立即发送给客户端，而不是等到整个响应处理完再发送。

• 检查服务器配置限制
  有些服务器（比如IIS）默认可能对100-continue的支持有限制。你可以检查一下服务器配置：
  比如在IIS的web.config中添加相关配置，确保服务器允许处理这类响应：

  <system.webServer>
    <serverRuntime enableSendfile="false" enableKernelOutputCache="false" />
  </system.webServer>
  

  这个配置会禁用一些可能干扰100响应发送的缓存机制。

• 抓包调试定位问题
  用Fiddler或者浏览器的开发者工具抓一下请求包，确认：

  1. 客户端是否真的发送了Expect: 100-continue头
  2. 服务器的响应状态是什么，有没有返回错误码（比如400）
     抓包能直观看到问题出在请求还是响应环节。

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