Firefox 中 ASP.Net MVC 中的压缩过滤器属性出现问题

Question

在 ASP.Net MVC 2 中，我使用以下压缩过滤器，在 Chrome 中它工作正常，但在 Firefox 3.3.6 中它返回奇怪的字符。

public class CompressAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        //get request and response 
        var request = filterContext.HttpContext.Request;
        var response = filterContext.HttpContext.Response;

        //get requested encoding 
        if (!string.IsNullOrEmpty(request.Headers["Accept-Encoding"]))
        {
            string enc = request.Headers["Accept-Encoding"].ToUpperInvariant();

            //preferred: gzip or wildcard 
            if (enc.Contains("GZIP") || enc.Contains("*"))
            {
                response.AppendHeader("Content-encoding", "gzip");
                response.Filter = new GZipStream(response.Filter, CompressionMode.Compress);
            }

            //deflate 
            else if (enc.Contains("DEFLATE"))
            {
                response.AppendHeader("Content-encoding", "deflate");
                response.Filter = new DeflateStream(response.Filter, CompressionMode.Compress);
            }
        }
        base.OnActionExecuting(filterContext);
    }
}

以下是 Firefox 显示的字符示例：

��������I�%&/m�{J�J��t��$�@ �iG#)�*��eVe]f@�흼��{���{��;�N'���?\fdl��J�ɞ!���?

原因是什么？

Answer 1

我发现一些事情会导致您自己的压缩出现问题。

第一的。某些情况会导致响应处理方式发生彻底改变（Server.Transfer，一个 HTTP 模块推迟到另一个 HTTP 模块）可能会清除标头，但保留流。 Fiddler 会很快告诉你是否是这种情况。一种可能性是，当您转到错误响应时会发生这种情况，并且 FF 情况下发生错误。自己强制解压流应该有助于诊断。

相反，一系列事件可能导致标头和/或压缩加倍，因此您最终会发送 gzip 的 gzip 等类似内容。更糟糕的是，过滤器可能在响应过程中被更改。

第三。仅放入 DeflateStream 或 GZipStream，因为过滤器无法正确处理使用分块编码的情况（缓冲关闭、调用 HttpResponse.Flush() 或发送大于允许的最大缓冲区大小的响应）。以下流类可以正确处理这种情况（它是对 Flush() 的重写来进行修复，我发现额外的公共属性在处理上述情况时很有用）。

public enum CompressionType
{
  Deflate,
  GZip
}
public sealed class WebCompressionFilter : Stream
{
  private readonly Stream _compSink;
  private readonly 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;
      default:
        throw new ArgumentException();
    }
  }
  public Stream Sink
  {
    get
    {
      return _finalSink;
    }
  }
  public CompressionType CompressionType
  {
    get
    {
      return _compSink is DeflateStream ? CompressionType.Deflate : CompressionType.GZip;
    }
  }
  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);
  }
}

第四。使用内容编码（而不是传输编码）时，HTTP 认为您实际上正在发送与使用不同编码不同的实体。 （传输编码认为您只是使用编码，以便使用更少的带宽，这正是我们通常真正想要的，但可惜对传输编码的支持并不常见，因此我们通过使用内容编码来代替） 。因此，您需要确保不同编码之间的电子标签（如果有）不同（在最后一个“字符之前添加 G 表示 gzip，添加 D 表示默认值应该可以解决问题，只是不要重复 mod -gzip 将其放在“字符后面的错误）。

第五。与此相关的是，您必须发送适当的 Vary 标头，因为您可以根据内容编码而变化。正确执行此操作意味着发送 Vary: Accept-Encoding，以指示您发送的内容将取决于该标题的值。因为这会导致 IE 出现问题（幸运的是，根据 MS 的说法，下一个版本将有一些改进），一些人改为发送 Vary: User-Agent（基于大多数用户代理要么接受压缩内容-编码或不编码，而不是有时请求而不是其他）。请注意，当您准备压缩时，您需要设置 Vary 标头，即使您没有这样做。

第六。即使您完美地完成了所有操作，开发早期的缓存中的某些内容也可能会造成混乱，因为您刚刚在缓存后更改了缓存规则。清除缓存。

如果这些都不符合要求，至少看看您在 Fiddler 这样的工具中看到的内容，以及手动解压缩发送到 FF 的流时看到的内容，它肯定会有所帮助。

顺便说一句，无论客户端偏好是什么，上面的代码都支持 GZip 而不是 Deflate。如果我要忽略客户声明的偏好顺序，我会反过来做。由于 GZip 是基于 Deflate 构建的，因此 GZip 总是比 Deflate 稍大。这种差异可以忽略不计，但更重要的是，与 deflate 数据相比，某些实现将花费更多的 CPU 时间来处理 g-zip 数据，这取决于架构和软件（因此只需在一个上进行测试）机器不会告诉您足够的信息来判断这是否适用），因此对于在低端计算机上运行浏览器的客户端来说，gzip 和 deflate 之间的显着差异可能不仅仅是下载 gzip 将发送的几个额外八位字节。