如何防止ASP.NET/IIS在失败时发送我的http头

我在生产环境中遇到了这种情况，但我无法在开发环境中重现。MyWebAPI创建一个状态代码为200的响应对象，并设置一些头

我们发现，如果管理员重新启动IIS，IIS会发回500个错误，但保留我的标题。这是一个问题，因为我正在设置缓存头，在本例中，客户端最终缓存了500个响应，这并不是我想要的

我想，当IIS决定杀死仍在进行中的请求以便能够重新启动时，这种情况会发生，但我无法证明这一点

---

有没有办法确保我永远不会发送500个包含缓存头的响应

我没有答案给你，但我想评论一下：

我想，当IIS决定杀死仍在进行中的请求以便能够重新启动时，这种情况会发生，但我无法证明这一点

使用简单页面：

<%@ Page Language="C#" debug="true"%>

<script runat="server">                
     void Page_Load() {        
        Response.Headers.Add("Stack","Overflow");
        System.Threading.Thread.Sleep(10000);     
     }
</script>

如果现在将应用程序池设置为在关闭池之前不要等待太长时间：

Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST'  -filter "system.applicationHost/applicationPools/add[@name='DefaultAppPool']/processModel" -name "shutdownTimeLimit" -value "00:00:03"

我告诉IIS在3秒钟后关闭DefaultAppPool，不管运行的请求是什么

现在，在浏览器中再次点击我们的页面，同时它正在执行。停止池或执行

iisreset.exe

现在，您将得到一个503（而不是500），其响应头如下所示：

Connection:close
Content-Length:326
Content-Type:text/html; charset=us-ascii
Date:Mon, 06 Jul 2015 04:21:31 GMT
Server:Microsoft-HTTPAPI/2.0

请注意，服务器不再是IIS，它现在是Microsoft HTTPAPI，这意味着请求已由IIS的内核模式部分而不是用户模式部分的http.sys响应

我们的自定义http头也不见了

所有这一切都意味着你上面的假设是不正确的，500条回复肯定来自其他地方

你在IIS日志中看到那些500了吗？如果是这样的话，它们发生在应用程序池消失之前

---

如果您无法在本地重现问题，并且无法在生产设备上运行失败的请求跟踪，则可能很难查明发生了什么。

谢谢。你的回答真的很有帮助。我们在dev中执行了相同的测试，也得到了503，但我们无法得到500。我没有意识到503来自微软的HTTPAPI。在prod中，500在IIS日志中。我们将启用失败的请求跟踪，以查看是否发生了这种情况。我会通知你的。

Connection:close
Content-Length:326
Content-Type:text/html; charset=us-ascii
Date:Mon, 06 Jul 2015 04:21:31 GMT
Server:Microsoft-HTTPAPI/2.0