【发布时间】：2014-12-08 13:01:51
【问题描述】：
我有一个ApiController，它通过 HTTP 的状态代码 307 重定向它来响应 POST 请求。它只使用来自标头的信息，因此此操作不需要请求的正文。这个动作相当于：
public HttpResponseMessage Post() {
var url;
// Some logic to construct the URL
var response = new HttpResponseMessage(HttpStatusCode.TemporaryRedirect);
response.Headers.Location = new System.Uri(url);
return response;
}
这很简单，但我想做一个改进。请求正文可能包含大量数据，因此我想利用 HTTP 状态代码 100 来提高此请求的效率。使用现在的控制器，对话可能如下所示：
> POST /api/test HTTP/1.1
> Expect: 100-continue
> ...
< HTTP/1.1 100 Continue
> (request body is sent)
< HTTP/1.1 307 Temporary Redirect
< Location: (the URL)
< ...
由于重定向操作不需要请求正文，我希望能够将对话缩短为：
> POST /api/controller HTTP/1.1
> Expect: 100-continue
> ...
< HTTP/1.1 307 Temporary Redirect
< Location: (the URL)
< ...
我花了一天的大部分时间研究如何做到这一点，但我无法提出解决方案。在我的研究中，我了解到：
-
ApiController的操作执行时，100 Continue已经发送。 -
ApiController构造时，100 Continue已经发送。 - 当
HttpApplication的PreRequestHandlerExecute事件被触发时，100 Continue响应尚未发送。 - 当
DelegatingHandler执行时，100 Continue已经被发送。
基于此，到目前为止我想出的最佳解决方案是创建一个HttpModule，它使用RequestContext 上的RouteData 来覆盖当相关ApiController 的接收者时的响应请求。然而，这远不是一个理想的解决方案，原因有很多（代码分离、没有利用 Web API 的参数绑定以及绕过ApiController 上的AuthorizeAttribute 中的额外逻辑）。
似乎必须有更好的解决方案，但我发现关于如何在 Web API 应用程序中正确处理 Expect: 100-continue 标头的信息很少。 实现此ApiController 以正确处理Expect: 100-continue 标头的最简单方法是什么？
【问题讨论】：
-
您使用的是 IIS 7 吗？
-
WebAPI 无法处理此标头，因为它在 IIS 中在 WebAPI 不知情的情况下在内核级别进行透明处理。
-
@AndrewCounts ...我就是这么说的。
-
@K.AlanBates 是的，我只是同意你的看法。 :)
-
@AndrewCounts 陷阱
标签： c# asp.net iis asp.net-web-api2 http-status-code-100