14

Expect: 100-continue我正在使用 ASP.NET MVC 实现一个 REST API，并且以请求标头的形式出现了一个小绊脚石，用于带有帖子正文的请求。

RFC 2616指出：

在接收到一个包含“100-continue”期望的 Expect 请求头字段的请求时，源服务器必须要么以 100（继续）状态响应并继续从输入流中读取，要么以最终状态码响应。源服务器在发送 100（继续）响应之前不能等待请求正文。如果它以最终状态码响应，它可以关闭传输连接，或者它可以继续读取并丢弃请求的其余部分。如果它返回一个最终状态码，它绝不能执行请求的方法。

这听起来像是我需要对请求做出两个响应，即它需要立即发送一个 HTTP 100 Continue 响应，然后继续从原始请求流（即HttpContext.Request.InputStream）读取而不结束请求，然后最终发送结果状态码（为了论证，假设它是 204 No Content 结果）。

所以，问题是：

  1. 我是否正确阅读规范，我需要对请求做出两个响应？
  2. 这如何在 ASP.NET MVC 中完成？

wrt (2) 在继续读取输入流之前，我尝试使用以下代码...

HttpContext.Response.StatusCode = 100;
HttpContext.Response.Flush();
HttpContext.Response.Clear();

...但是当我尝试设置最终的 204 状态代码时，我得到了错误：

System.Web.HttpException：发送 HTTP 标头后服务器无法设置状态。

4

3 回答 3

17

默认情况下，.NET 框架总是发送expect: 100-continue每个 HTTP 1.1 帖子的标头。这种行为可以通过如下System.Net.ServicePoint.Expect100Continue属性以编程方式控制每个请求：

HttpWebRequest httpReq = GetHttpWebRequestForPost();
httpReq.ServicePoint.Expect100Continue = false;

它也可以通过编程方式进行全局控制：

System.Net.ServicePointManager.Expect100Continue = false;

...或通过配置全局：

<system.net>
  <settings>
    <servicePointManager expect100Continue="false"/>
  </settings>
</system.net>

感谢 Lance Olson 和Phil Haack提供此信息。

于 2009-06-23T21:20:29.807 回答
2

100-continue 应该由 IIS 处理。你有什么理由要明确地这样做吗？

于 2009-05-18T21:12:10.973 回答
2

IIS 处理 100。

也就是说，不，这不是两个回应。在 HTTP 中，当 Expect: 100-continue 作为消息头的一部分出现时，客户端应该等到收到响应后再发送内容。

由于 asp.net 的架构方式，您几乎无法控制输出流。每当您刷新时，写入流的任何数据都会自动放入带有分块编码的 200 响应中，无论您是否处于缓冲模式。

可悲的是，所有这些东西都隐藏在各处的内部方法中，结果是，如果你依赖 asp.net，就像 MVC 一样，你几乎无法绕过它。

等到您尝试以非缓冲方式访问输入流。满满的痛苦。

塞布

于 2009-06-12T00:57:15.993 回答