Question

On the server I’m forcing compression with a custom message handler. The handler checks the Accept-Encoding header and if it is supported (e.g. GZip) will swap out the HttpResponseMessage.Content with an instance of CompressedContent. This simply compresses the original content like so:

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();
    }
}

On the client, we can achieve the decompression by checking the Content-Encoding header and using another HttpContent type to perform the decompression:

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();
    }
}

The part I am unsure of is whether we should be using a custom HttpContent type to do the decompression. On the server it makes sense to do this since we don’t really have other way of touching the response stream. On the client however, this could be done by decompressing the standard StreamContent directly or even with a custom HttpClient implementation.

Answer 1

Message handlers can be used on the client as well, in conjunction with HttpClient, to process the request/response. In your case that would be useful to provide a reverse process to that happening on the server.

This is the beautiful symmetry of ASP.NET Web API.

A great article on client side message handlers is here – http://byterot.blogspot.ch/2012/06/aspnet-web-api-client-delegating.html

Another example can be found here, on Henrik’s blog – it’s a bit old (against beta), but the gist is still the same: http://blogs.msdn.com/b/henrikn/archive/2012/02/16/extending-httpclient-with-oauth-to-access-twitter.aspx