如何实现API Gzip压缩OwinMiddleware？求最佳实践

刚接触OWIN中间件确实会有点懵，毕竟它的响应模型和你熟悉的ASP.NET HttpContext不太一样——没有现成的Content属性让你直接读取响应内容。不过别担心，我们可以通过替换响应流的方式来捕获并压缩API的响应，这是OWIN生态里处理这类需求的标准做法。

核心思路：替换响应流捕获内容 #

OWIN的IOwinContext.Response是基于流设计的，要修改响应内容，我们需要先把原始的响应流替换成一个内存流，让后续中间件把内容写入这个内存流；等请求处理完成后，再读取内存流的内容进行压缩，最后写入原始的响应流。

修改后的完整代码 #

这里是调整后的实现，解决了你的问题，同时遵循OWIN的最佳实践：

using System.IO.Compression;
using System.Text;

public class ApiResponseCompression : OwinMiddleware
{
    private const string AcceptEncodingHeader = "Accept-Encoding";
    private const string ContentEncodingHeader = "Content-Encoding";
    private const string ContentTypeHeader = "Content-Type";
    private const string GzipEncoding = "gzip";
    
    // 维护一个可压缩的内容类型集合，根据你的业务需求调整
    private readonly HashSet<string> _compressibleContentTypes = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
    {
        "application/json",
        "text/plain",
        "text/html",
        "text/css",
        "application/javascript",
        "application/xml"
    };

    public ApiResponseCompression(OwinMiddleware next) : base(next) { }

    public override async Task Invoke(IOwinContext context)
    {
        var request = context.Request;
        var response = context.Response;

        // 1. 检查请求是否支持gzip压缩
        if (request.Headers.ContainsKey(AcceptEncodingHeader) && 
            request.Headers[AcceptEncodingHeader].IndexOf(GzipEncoding, StringComparison.OrdinalIgnoreCase) >= 0)
        {
            var originalResponseBody = response.Body;
            try
            {
                // 2. 用内存流捕获后续中间件的响应内容
                using (var memoryStream = new MemoryStream())
                {
                    response.Body = memoryStream;

                    // 3. 调用后续中间件处理请求
                    await Next.Invoke(context);

                    // 4. 检查响应是否是我们需要压缩的类型
                    bool shouldCompress = false;
                    if (response.Headers.ContainsKey(ContentTypeHeader))
                    {
                        // 去掉Content-Type里的参数（比如charset=utf-8），只保留主类型
                        var contentType = response.Headers[ContentTypeHeader].FirstOrDefault()?.Split(';')[0].Trim();
                        shouldCompress = !string.IsNullOrEmpty(contentType) && _compressibleContentTypes.Contains(contentType);
                    }

                    // 5. 如果需要压缩，处理内容并写入原始流
                    if (shouldCompress && response.StatusCode >= 200 && response.StatusCode < 300)
                    {
                        memoryStream.Seek(0, SeekOrigin.Begin);

                        // 添加压缩相关的响应头
                        response.Headers.Add(ContentEncodingHeader, new[] { GzipEncoding });
                        response.Headers.Append("Vary", AcceptEncodingHeader);
                        response.Headers.Remove("Content-Length"); // 压缩后长度变化，移除原始长度

                        // 压缩内容并写入原始响应流
                        using (var gzipStream = new GZipStream(originalResponseBody, CompressionMode.Compress, leaveOpen: true))
                        {
                            await memoryStream.CopyToAsync(gzipStream);
                            await gzipStream.FlushAsync();
                        }
                        return;
                    }

                    // 6. 如果不需要压缩，直接把内存流内容复制回原始流
                    memoryStream.Seek(0, SeekOrigin.Begin);
                    await memoryStream.CopyToAsync(originalResponseBody);
                }
            }
            finally
            {
                // 7. 无论如何都要恢复原始响应流，避免资源泄漏
                response.Body = originalResponseBody;
            }
        }

        // 如果不满足压缩条件，直接传递请求给后续中间件
        await Next.Invoke(context);
    }
}

OwinMiddleware的最佳实践 #

结合这个场景，总结几个关键的最佳实践：

• 始终处理流的生命周期：替换响应流后，一定要在finally块里恢复原始流，否则会导致后续中间件或服务器无法正确处理响应，甚至引发资源泄漏。
• 精准判断压缩场景：
  • 只对支持gzip的请求压缩（通过Accept-Encoding头判断）
  • 只对可压缩的内容类型压缩（避免压缩图片、视频这类已经压缩过的资源）
  • 只对成功响应（2xx状态码）压缩，没必要处理错误响应
• 正确设置缓存相关头：添加Vary: Accept-Encoding头，确保缓存服务器能区分压缩和未压缩的响应，避免返回错误的内容给用户。
• 避免硬编码配置：像可压缩的内容类型这类配置，最好做成可配置的（比如通过构造函数注入），而不是硬编码在类里，方便后续修改。
• 考虑大响应的内存压力：如果你的API经常返回超大响应，内存流可能会占用过多内存。这种情况下可以考虑流式压缩——不需要把整个响应读到内存，而是边读边压缩边写入响应流，不过实现起来会更复杂一些。

内容的提问来源于stack exchange，提问作者AllmanTool