原来的测试程序，在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 理解不了接收到的数据，所以就出错了。