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

我创建了一个名为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支持的Web浏览器中查看响应时，会出现如下错误：

“XML解析错误：未关闭的令牌位置： http：//webserver1/1234.xml第78行，第1列：”

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

如果我注释掉AddGZip线，它可以正常工作。 但是我真的想支持GZip，因为XML可能非常大。

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

戴夫

Answer 1

使用DeflateStream （ GZipStream构建于DeflateStream并inheritance问题*）存在一个问题（或者可能是我在任何地方都没有看到的非常聪明的特性），其中刷新可能会丢失数据。

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

 public enum CompressionType { Deflate, GZip } /// 
 /// 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. /// 
 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编码的大多数用户代理也支持deflate-encoding。 虽然使用deflate进行的大小改进可以忽略不计（实际上是几个字节），但某些体系结构上的某些库处理deflate的效果要好得多（这适用于压缩和解压缩），因此总是值得利用HTTP压缩来支持defz over gzip。

Answer 2

您是否尝试过通过IIS添加gzip？ 有一个问题 ，所以看看它是什么。 基本上，IIS执行所有压缩，因此您不必这样做。