我看到人们只是检测到请求浏览器是否支持 http 压缩。如果支持则检测是否支持 gzip 或 deflate。
然后将属性添加到响应对象，如
HttpContext.Current.Response.AppendHeader("Content-encoding", "gzip");
或
HttpContext.Current.Response.AppendHeader("Content-encoding", "deflate");
我只需要知道谁真正comresee 响应。它是网络服务器还是 asp.net 工作进程。请详细讨论谁以及如何压缩响应。谢谢
【问题讨论】：
实际上，您在此处显示的标头并未进行压缩。进行压缩的是您在 Response.Filter 上设置的 Stream 类，并且此压缩是由 Asp.Net 进行的，例如：
if (acceptEncoding.Contains("gzip"))
{
// gzip
app.Response.Filter = new GZipStream(prevUncompressedStream, CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", "gzip");
}
else if (acceptEncoding.Contains("deflate") || acceptEncoding == "*")
{
// deflate
app.Response.Filter = new DeflateStream(prevUncompressedStream, CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", "deflate");
}
如果你这样做了，那么压缩是由 asp.net 而不是 IIS 完成的。然后 iis 检测到该文件已全部准备好压缩并且没有再次压缩。有时我看到此检测失败并且页面根本不显示，因此在这种情况下您停用 iis 压缩。
这是 asp.net 中的 gZipStream 类 http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream.aspx
因此，如果您设置 GZipStream，则 asp.net 工作进程对 DeflateStream 进行了压缩
这里是 asp.net 使用 GZipStream 压缩文件的示例 http://www.dotnetperls.com/gzipstream
我更喜欢在 asp.net 上而不是 iis 上进行压缩，因为我对它有更多的控制权。
【讨论】：