Response.End() 与Response.Close()的区别
原来的测试程序，在Response.Flush()之后，调用Response.End()，而出错的程序在Response.Flush()之后，调用Response.Close()。直接将Close调用改为End后，问题消失。看来问题的根源就在这里了。
MSDN对两个方法给出的注释是：
Close断开客户端的连接。
End结束当前页面的执行。
看来确有不同。通过查看源码，Close 是服务器主动断开连接，然后设置客户端断开连接的标志，没有其他的操作。而 End 会再次 Flush 当前的内容，然后设置页面结束的标志，然后引发 EndRequest 事件，并不立即断开客户端连接。
正是由于采取了不同的方法，导致最终的结果不同。Close 采用强硬手段，直接断开客户端连接，也就使得 xmlhttp 组件不知道内容是否已经传完，于是导致取不到内容。而 End 采用常规方法，一步步操作，在 EndRequest 中明确告知后续操作自己正常结束，之后由后续操作正常断开客户端。说到这里，就不能不说，这跟.Net中http请求的生命周期相关。在http请求的生命周期中，Close 和 End 就像马拉松的折返点一样，Close 相当于到了折返点就直接坐汽车回起点了，而 End 相当于到了折返点继续跑回去。那么最终的结果肯定是不同的。
到目前为止，还是没有解释为什么启用IIS压缩功能之前是正常的，启用压缩功能之后就出错了呢？其实我们已经很接近真相了。因为启用压缩之后，服务器必须明确告诉客户端，我传给你的内容是经过压缩的，压缩方法是GZIP。这样客户端才能正确解析内容。而这个信息是放在http响应头的 Content-Encoding 中的。由于 Close 主动断开了连接，使得IIS没有机会加上这个响应头信息。所以就造成了采用Close方式时，xmlhttp 组件获取不到这个信息。由于没启用压缩之前，内容已经被接收完毕，并且xmlhttp可以正常解析，所以在启用压缩之前，即使缺少 Content-Encoding 信息，功能也是正常的。启用压缩之后，xmlhttp 理解不了接收到的数据，所以就出错了。
不要使用Response.Close()
1 因为:Close（）方法会调用HttpWorkerRequest.CloseConnection()方法。终止(Terminate)与客户端的套接字连接，并使得服务器，客户端以及之间设施上的缓存（buffer）失效。导致发送到客户端的数据丢失。
2 方法Response.End()是为了兼容经典ASP程序，在Asp.NET 1.0中引入的，在调用后会抛出ThreadAbortException异常。成功时则中止（abort）当前的线程，处理管道触发EndRequest事件，不再处理之后的代码。会以同步的方式将响应内容发送（flush）给客户端。
由于.NET 设计原因，Response.End()在WebForm框架下可以终止代码执行，不再处理End()之后的代码。在MVC框架下则只是返回响应流，不会中止代码执行。
3 此外还可以使用HttpApplication.CompleteRequest()方法结束请求。
Response.Flush();
this.Context.ApplicationInstance.CompleteRequest();
综上所述：只有代码发生错误（恶意的攻击），希望终止对于客户端的响应/连接时才可以使用Response.Close()
如果你想结束请求，并向客户端发送请求则应该优先使用HttpApplication.CompleteRequest()方法。
参考文章：
1 http://weblogs.asp.net/hajan/why-not-to-use-httpresponse-close-and-httpresponse-end