GZipStream 正在切断 XML 的最后一部分

Question

我创建了一个名为 AddGZip 的扩展方法，如下所示：

public static void AddGZip(this HttpResponse response)
{
    response.Filter = new GZipStream(response.Filter, CompressionMode.Compress);
    response.AppendHeader("Content-Encoding", "gzip");
}

这是一个非常精简的代码版本：

var response = HttpContext.Current.Response;
var request = HttpContext.Current.Request;
var result = File.ReadAllText(path);
if (request.SupportsGZip)
{
  response.AddGZip();
}
response.Write(result);
response.Flush();

当您在支持 GZip 的网络浏览器中查看响应时，您会收到如下错误：

"XML 解析错误：未关闭的令牌 地点：http://webserver1/1234.xml 第 78 行，第 1 列："

当我查看源代码时，它基本上错过了 XML 文件末尾的最后一个 >。所以 1 或 2 个字节。

如果我注释掉 AddGZip Line 它工作正常。不过我真的很想支持 GZip，因为 XML 可能很大。

有人对我有什么建议吗？我试过检查很多博客，但似乎没有针对此类错误的解决方案。

戴夫

Answer 1

DeflateStream（GZipStream 基于DeflateStream 并继承了问题*）存在一个问题（或者可能是一个我在任何地方都没有看到合理的非常聪明的功能），其中刷新可能会丢失数据。

Response.Flush() 将冲洗过滤器。解决方案是使用一个知道压缩和底层接收器的包装器，并且只刷新后者：

public enum CompressionType
{
    Deflate,
    GZip
}
/// <summary>
/// Provides GZip or Deflate compression, with further handling for the fact that
/// .NETs GZip and Deflate filters don't play nicely with chunked encoding (when
/// Response.Flush() is called or buffering is off.
/// </summary>
public class WebCompressionFilter : Stream
{
    private Stream _compSink;
    private Stream _finalSink;
    public WebCompressionFilter(Stream stm, CompressionType comp)
    {
        switch(comp)
        {
            case CompressionType.Deflate:
                _compSink = new DeflateStream((_finalSink = stm), CompressionMode.Compress);
                break;
            case CompressionType.GZip:
                _compSink = new GZipStream((_finalSink = stm), CompressionMode.Compress);
                break;
        }
    }
    public override bool CanRead
    {
        get
        {
            return false;
        }
    }
    public override bool CanSeek
    {
        get
        {
            return false;
        }
    }
    public override bool CanWrite
    {
        get
        {
            return true;
        }
    }
    public override long Length
    {
        get
        {
            throw new NotSupportedException();
        }
    }
    public override long Position
    {
        get
        {
            throw new NotSupportedException();
        }
        set
        {
            throw new NotSupportedException();
        }
    }
    public override void Flush()
    {
        //We do not flush the compression stream. At best this does nothing, at worse it
        //loses a few bytes. We do however flush the underlying stream to send bytes down the
        //wire.
        _finalSink.Flush();
    }
    public override long Seek(long offset, SeekOrigin origin)
    {
        throw new NotSupportedException();
    }
    public override void SetLength(long value)
    {
        throw new NotSupportedException();
    }
    public override int Read(byte[] buffer, int offset, int count)
    {
        throw new NotSupportedException();
    }
    public override void Write(byte[] buffer, int offset, int count)
    {
        _compSink.Write(buffer, offset, count);
    }
    public override void WriteByte(byte value)
    {
        _compSink.WriteByte(value);
    }
    public override void Close()
    {
        _compSink.Close();
        _finalSink.Close();
        base.Close();
    }
    protected override void Dispose(bool disposing)
    {
        if(disposing)
        {
            _compSink.Dispose();
            _finalSink.Dispose();
        }
        base.Dispose(disposing);
    }
}

还值得注意的是，大多数支持 gzip-encoding 的用户代理也支持 deflate-encoding。虽然使用 deflate 对大小的改进可以忽略不计（字面意思是几个字节），但某些架构上的一些库对 deflate 的处理要好得多（这适用于压缩和解压缩），因此始终值得使用 deflate 而不是使用 HTTP 压缩的 gzip。

Answer 2

您是否尝试过通过 IIS 添加 gzip？有一个关于它的question，所以看看它是关于什么的。基本上，IIS 会完成所有压缩，因此您不必这样做。