我有一个相当糟糕的标准 .net MVC 4 Web API 应用程序。

 public class LogsController : ApiController
{

    public HttpResponseMessage PostLog(List<LogDto> logs)
    {
        if (logs != null && logs.Any())
        {
            var goodLogs = new List<Log>();
            var badLogs = new List<LogBad>();

            foreach (var logDto in logs)
            {
                if (logDto.IsValid())
                {
                    goodLogs.Add(logDto.ToLog());
                }
                else
                {
                    badLogs.Add(logDto.ToLogBad());
                }
            }

            if (goodLogs.Any())
            {
                _logsRepo.Save(goodLogs);
            }

            if(badLogs.Any())
            {
                _logsBadRepo.Save(badLogs);
            }


        }
        return new HttpResponseMessage(HttpStatusCode.OK);
    }
}

一切正常，我的设备能够向我发送他们的日志并且运行良好。但是现在我们开始担心传输数据的大小，我们想看看是否接受使用 GZIP 压缩的帖子？

我该怎么做？它是在 IIS 中设置还是我可以使用 Action Filters？

编辑 1

根据 Filip 的回答，我的想法是我需要在请求到达我的 Controller 之前拦截请求的处理。如果我可以在 Web api 框架尝试将请求的主体解析为我的业务对象之前捕获请求，则失败，因为请求的主体仍然是压缩的。然后我可以解压缩请求的主体，然后将请求传回处理链，希望 Web Api 框架能够将(解压缩的)主体解析为我的业务对象。

看起来使用 DelagatingHandler 是可行的方法。它允许我在处理期间访问请求，但在我的 Controller 之前。所以我尝试了以下？

 public class gZipHandler : DelegatingHandler
{

    protected override System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
    {
        string encodingType = request.Headers.AcceptEncoding.First().Value;

        request.Content = new DeCompressedContent(request.Content, encodingType);

        return base.SendAsync(request, cancellationToken);
    }
}

public class DeCompressedContent : HttpContent
{
    private HttpContent originalContent;
    private string encodingType;

    public DeCompressedContent(HttpContent content, string encodType)
    {
        originalContent = content;
        encodingType = encodType;
    }

    protected override bool TryComputeLength(out long length)
    {
        length = -1;

        return false;
    }


    protected override Task<Stream> CreateContentReadStreamAsync()
    {
        return base.CreateContentReadStreamAsync();
    }

    protected override Task SerializeToStreamAsync(Stream stream, TransportContext context)
    {
        Stream compressedStream = null;

        if (encodingType == "gzip")
        {
            compressedStream = new GZipStream(stream, CompressionMode.Decompress, leaveOpen: true);
        }

        return originalContent.CopyToAsync(compressedStream).ContinueWith(tsk =>
        {
            if (compressedStream != null)
            {
                compressedStream.Dispose();
            }
        });
    }



}

这似乎工作正常。 SendAsync 方法在我的 Controller 和 DecompressedContent 的构造函数被调用之前被调用。然而，SerializeToStreamAsync 从未被调用，所以我添加了 CreateContentReadStreamAsync 以查看是否应该在此处进行解压缩，但也没有被调用。

我觉得我已经接近解决方案了，但只需要一点点额外的东西就可以解决问题。

最佳答案

我有同样的要求将 gzip 数据发布到 .NET web api Controller 。我想出了这个解决方案:

public class GZipToJsonHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
                                                           CancellationToken cancellationToken)
    {
        // Handle only if content type is 'application/gzip'
        if (request.Content.Headers.ContentType == null ||
            request.Content.Headers.ContentType.MediaType != "application/gzip")
        {
            return base.SendAsync(request, cancellationToken);
        }

        // Read in the input stream, then decompress in to the outputstream.
        // Doing this asynronously, but not really required at this point
        // since we end up waiting on it right after this.
        Stream outputStream = new MemoryStream();
        Task task = request.Content.ReadAsStreamAsync().ContinueWith(t =>
            {
                Stream inputStream = t.Result;
                var gzipStream = new GZipStream(inputStream, CompressionMode.Decompress);

                gzipStream.CopyTo(outputStream);
                gzipStream.Dispose();

                outputStream.Seek(0, SeekOrigin.Begin);
            });

        // Wait for inputstream and decompression to complete. Would be nice
        // to not block here and work async when ready instead, but I couldn't 
        // figure out how to do it in context of a DelegatingHandler.
        task.Wait();

        // This next section is the key...

        // Save the original content
        HttpContent origContent = request.Content;

        // Replace request content with the newly decompressed stream
        request.Content = new StreamContent(outputStream);

        // Copy all headers from original content in to new one
        foreach (var header in origContent.Headers)
        {
            request.Content.Headers.Add(header.Key, header.Value);
        }

        // Replace the original content-type with content type
        // of decompressed data. In our case, we can assume application/json. A
        // more generic and reuseable handler would need some other 
        // way to differentiate the decompressed content type.
        request.Content.Headers.Remove("Content-Type");
        request.Content.Headers.Add("Content-Type", "application/json");

        return base.SendAsync(request, cancellationToken);
    }
}

使用这种方法，通常使用 JSON 内容和自动模型绑定(bind)的现有 Controller 无需任何更改即可继续工作。

我不确定为什么其他答案被接受了。它提供了一种用于处理响应(这很常见)而不是请求(这并不常见)的解决方案。 Accept-Encoding 头用于指定可接受的响应编码，与请求编码无关。

关于c# - 如何启用 .Net web-API 以接受 g-ziped 帖子，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12345292/