1

在服务器上，我使用自定义消息处理程序强制压缩。处理程序检查Accept-Encoding标头，如果它受支持（例如 GZip），将HttpResponseMessage.Content用CompressedContent. 这只是像这样压缩原始内容：

protected override async Task SerializeToStreamAsync(Stream stream, TransportContext context)
{
    Ensure.Argument.NotNull(stream, "stream");

    using (content) // original content
    {
        // creates a new GZip/Deflate stream
        var compressed = GetStream(CompressionMode.Compress, stream);
        await content.CopyToAsync(compressed);
        compressed.Dispose();
    }
}

在客户端，我们可以通过检查Content-Encodingheader并使用另一种HttpContent类型进行解压来实现解压：

protected async override Task SerializeToStreamAsync(Stream stream, TransportContext context)
{
    Ensure.Argument.NotNull(stream, "stream");

    using (content)
    {
        var compressed = await content.ReadAsStreamAsync();
        var decompressed = GetStream(CompressionMode.Decompress, compressed);
        await decompressed.CopyToAsync(stream);
        decompressed.Dispose();
    }
}

我不确定的部分是我们是否应该使用自定义HttpContent类型来进行解压缩。在服务器上这样做是有意义的，因为我们真的没有其他方式来接触响应流。然而，在客户端上，这可以通过StreamContent直接解压缩标准甚至使用自定义HttpClient实现来完成。

4

1 回答 1

2

消息处理程序也可以在客户端上与 一起使用HttpClient，以处理请求/响应。在您的情况下，为服务器上发生的事情提供反向过程将很有用。

这就是 ASP.NET Web API 的美丽对称。

关于客户端消息处理程序的一篇很棒的文章在这里 - http://byterot.blogspot.ch/2012/06/aspnet-web-api-client-delegating.html

另一个例子可以在这里找到，在 Henrik 的博客上 - 它有点旧（针对 beta），但要点仍然相同：http: //blogs.msdn.com/b/henrikn/archive/2012/02/16/扩展-httpclient-with-oauth-to-access-twitter.aspx

于 2012-09-11T19:51:27.573 回答