我有一个WCF服务，它提供了一个端点来动态生成QR-Code映像。首先将映像写入内存流tempStream。然后在端点中有以下代码:
HttpResponse response = HttpContext.Current.Response;
response.Clear();
response.ClearContent();
response.ClearHeaders();
response.Buffer = false;
response.ContentType = "image/png";
response.CacheControl = "No-Cache";
response.AddHeader("Content-Length", tempStream.Length.ToString())
response.AddHeader("Accept-Ranges", "bytes");
tempStream.WriteTo(response.OutputStream);
response.Flush();
response.End();
它在Firefox中运行良好。如果我手动点击端点，图像将被下载，如果我在img标记中将端点引用为src属性，则图像将内联加载。然而，在IE中，图像不会在img标记中内联加载，如果我尝试手动命中端点，它会第一次加载完整图像，但任何后续刷新(似乎直到浏览器重新启动)，它只加载图像的一部分。
在F12窗口的network选项卡中，它似乎正在从服务器下载恰好1.00 KB的数据(包括标头)，这意味着它获得了大约750 KB的图像数据。然后，它向服务器发出另一个相同的请求，只返回报头，不返回图像数据。Content-Length标题被正确设置为图像的大小;IE只是不能下载那么多。同样，Firefox也可以。
我的同事建议我在Web.config中将transferMode设置为Streamed，我这样做了，但这也不起作用。如何让IE一次性下载整个图像?
我应该注意到，当在Visual Studio的IIS Express服务器中运行WCF服务时，Internet Explorer工作正常。只有当应用程序部署到IIS 7.5时才会出现问题。
编辑2:
我只是将Thread.Sleep(1000)添加到响应中，就在response.End()之前，它解决了这个问题。IE现在下载整个响应，不再尝试发出第二次请求。为什么? !response.Flush();应该阻止请求并在response.End()被调用之前向客户端发出所有数据，据我所知，response.End()也会刷新流，因此手动调用Flush()是多余的。为什么显式地阻塞线程一秒钟使其工作?我还应该注意到，如果我不放入Thread.Sleep(1000)，它仍然适用于第一个请求，因为. net必须在每次appool重新启动时对后端进行jit编译，这会阻塞请求一段时间，就像Thread.Sleep(1000)一样。
试试这个:
response.AddHeader("Content-Disposition", "filename=" + fileName);
好了，我现在解出来了。而不是使用HttpContext.Current。响应，我现在使用WebOperationContext.Current.OutgoingResponse。此外，不是写入响应的输出流，而是从端点返回一个流对象，特别是我保存图像的MemoryStream(在它已被寻回0之后)。在传输完成之前，似乎没有一致的方式将写入操作写入HttpResponse块，因此请求总是结束得太快。就连Firefox也在处理大图片时遇到了问题。从端点函数返回一个Stream对象显然使WCF在结束请求之前等待直到所有数据发送完毕。