Regarding httpcompression asp.net



我看到人们只是检测请求浏览器是否支持HTTP压缩。如果支持,则检测支持gzip或deflate。

然后给响应对象添加属性,比如

HttpContext.Current.Response.AppendHeader("Content-encoding", "gzip");

HttpContext.Current.Response.AppendHeader("Content-encoding", "deflate");

我只需要知道谁真正收到了回复。是webserver进程还是asp.net工作进程。请详细讨论谁和如何压缩响应。由于

实际上您在这里显示的标题并没有进行压缩。进行压缩的是您在响应上设置的流类。过滤器和此压缩是由Asp。例如:

    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压缩。

这是gZipStream类是在asp.net内部http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream.aspx

所以asp.net工作进程进行压缩,如果你设置GZipStream, DeflateStream

下面是一个使用GZipStream的asp.net文件压缩的例子http://www.dotnetperls.com/gzipstream

我更喜欢在asp.net上进行压缩,而不是在iis上,因为我有更多的控制。

最新更新