“内容编码”如果发生异常，标头将从 HttpHandler 响应中消失

Question

我有一个自定义的 HttpHandler，在其中手动启用输出压缩，如下所示：

context.Response.AppendHeader("Content-encoding", "gzip");
context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);

这对于大多数请求来说效果很好，但是当遇到异常时，“Content-encoding”标头会从响应中消失，而压缩过滤器仍保留在原位。结果是错误页面是 gzip 压缩的，但浏览器没有收到表明这一事实的标头。然后，浏览器尝试将仍然压缩的数据显示为文本，即 gobbledygook。

完整的测试用例代码如下所示。尝试交替禁用压缩或不抛出异常。

任何人都可以解释为什么“内容编码”标头消失吗？

我想我可以简单地启用压缩作为处理程序执行的最后一件事，这样，如果遇到异常，它永远不会到达添加压缩过滤器的点；但我所看到的行为让我觉得这是一个错误。有人能证实吗？

public class TestHandler : IHttpHandler 
{
    public void ProcessRequest(HttpContext context)
    {
        CompressResponse(context);
        context.Response.Write("Hello world");

        // Throw an exception for testing purposes
        throw new Exception("Just testing...");
    }

    private void CompressResponse(HttpContext context)
    {
        string acceptEncoding = context.Request.Headers["Accept-Encoding"];
        if (String.IsNullOrEmpty(acceptEncoding))
        {
            return;
        }

        // gzip or wildcard
        if (acceptEncoding.ToLower().Contains("gzip") || acceptEncoding.Contains("*"))
        {
            context.Response.AppendHeader("Content-encoding", "gzip");
            context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);
            return;
        }

        // Also handles deflate (not shown here)
        // <snip>
    }

    public bool IsReusable
    {
        get { return true; }
    }
}

编辑：我在测试用例中看到的仍然编码的响应的屏幕截图： https://i.sstatic .net/R3Wmq.png

Answer 1

我也遇到了这个问题。追踪起来很复杂。我不确定整个情况的具体细节，但我认为发生的是内存泄漏。

当您第一次执行此操作时：

context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);

您正在将非托管资源分配给过滤器。通常，这将被包装在 using 语句中，以便在出现任何问题时能够正确处理它。

因此，当出现问题时，就会出现问题。 Filter 包含一个流，即使响应被写入时出现黄屏死机，该流仍处于打开状态。随之而来的是疯狂（如屏幕截图所示）。

不要害怕！实际上有一个简单的方法可以解决这个问题。丢弃过滤器。幸运的是，已经有一个地方可以应用这种过滤器处置的全局检查。

global.asax.cs

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
        filters.Add(new HandleErrorAttribute());//default handler
        filters.Add(new HandleErrorEncodingAttribute());//extra check for filter disposal
}

错误处理程序命名空间

public class HandleErrorEncodingAttribute : FilterAttribute, IExceptionFilter
{
    public virtual void OnException(ExceptionContext filterContext)
    {
        if (filterContext == null)
        {
            throw new ArgumentNullException("filterContext");
        }
        if (filterContext.IsChildAction)
        {
            return;
        }
        // If custom errors are disabled, we need to let the normal ASP.NET exception handler
        // execute so that the user can see useful debugging information.
        if (filterContext.ExceptionHandled || !filterContext.HttpContext.IsCustomErrorEnabled)
        {
            filterContext.HttpContext.Response.Filter.Dispose();//fixes response stream
            return;
        }
    }
}

Answer 2

如果出现异常，那么服务器将刷新当前设置的标头和内容，因为它们是错误的，就像您在出现异常之后所做的那样。

至少，很明显，您要发送的 200 状态（因为所有不更改状态的成功响应都会发送 200，并且在出现未处理的异常时，它不再成功）是错误的，但其他所有相关内容你想做但未能实现的事情，所以一切都是错误的，一切都会过去。

但过滤器不会重置。

如果合适，请重置错误页面中的标题，或者不要设置过滤器，除非您可以确定一切都已准备好刷新。我会选择前者，没有理由不能压缩错误页面。

如果您调用了Flush()，则无法发送标头，因为好吧，因为您已经刷新了。标题要去哪里？

Answer 3

当我在 WebForms 应用程序上强制使用 gzip 时，也发生了同样的事情。为了修复它，我必须清除 Global.asax.cs 中 Application_Error 方法中的过滤器。

protected void Application_Error(Object sender, EventArgs e)
{
    Response.Filter = null;
}

发生这种情况的原因是 b/c 在应用程序出现错误之前设置了过滤器。由于某种原因，黄屏错误消息会清除内容编码标头，但不会对响应过滤器执行任何操作。

Answer 4

我测试了你的代码，没有发现任何问题。是的，gzip 没有设置，但是过滤器也没有设置，asp 获得了控制权并发送错误。

强制标头刷新会产生真正的问题

 CompressResponse(context);
 context.Response.Flush(); 

如果我强制 gzip 标头，则页面无法正确呈现。

两个人认为这可能是你的问题。您没有设置页面编码

context.Response.ContentEncoding = new UTF8Encoding();

，也没有设置 ContentType

context.Response.ContentType = "text/plain";

也许这就是您无法正确渲染页面的原因。然而，在我的测试中，即使如此，您描述的问题也不会出现。