HttpClient 2.2 is now stable

HttpClient 2.2 is now stable

Rate This
  • Comments 31

As promised, we’ve just pushed the RTM version of HttpClient 2.2 to NuGet. This version adds support for automatic decompression. As announced here, this doesn’t require a dependency on Microsoft.Bcl.Compression. This allowed us to support automatic decompression on more platforms and without forcing your projects to change the CPU architecture.

It’s worth noting that we didn’t make any changes since the RC version we published a week ago (despite changing the version).

How to use automatic decompression

(For the sake of keeping this post self-contained I’ve copied the content from the post that introduced automatic decompression)

First, automatic decompression is not enabled by default for HttpClient. To use it, you need to set the AutomaticDecompression property on HttpClientHandler to GZip or Deflate. This API follows the optional feature pattern; meaning it exposes an API that indicates whether a particular feature is supported. Automatic decompression support is indicated with the SupportsAutomaticDecompression property.

If an implementation of HttpClient doesn’t support automatic decompression, it returns false from the SupportsAutomaticDecompression property and throws a NotSupportedException from the setter and getter for the AutomaticDecompression property.

With this pattern in mind, using automatic decompression looks like this:

var handler = new HttpClientHandler();
if (handler.SupportsAutomaticDecompression)
{
    handler.AutomaticDecompression = DecompressionMethods.GZip |
                                     DecompressionMethods.Deflate;
}
var httpClient = new HttpClient(handler);
var str = await httpClient.GetStringAsync("http://en.wikipedia.org/wiki/Gzip");

The request then provides the additional Accept-Encoding header:

GET http://en.wikipedia.org/wiki/Gzip HTTP/1.1
Host: en.wikipedia.org
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Servers that choose to support it will respond and indicate the compression algorithm they used. In this example, the server compressedt he body using gzip:

HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Wed, 13 Mar 2013 14:04:24 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 17765
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-Language: en
Last-Modified: Tue, 05 Mar 2013 03:38:51 GMT
Content-Encoding: gzip
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Vary: Accept-Encoding,Cookie
Age: 179

The response stream that HttpClient returns to you will automatically decompress the result using the appropriate algorithm. On my machine I got the following results:

Content-Length http://en.wikipedia.org/wiki/Gzip

This yields to a reduction by 77%. Needless to say, the actual results depend on the request and how well it compresses. So your results will naturally vary.

Summary

We’ve just shipped the RTM version of HttpClient 2.2, which updates HttpClient by adding support for automatic decompression. It's supported on .NET 4.0, Windows Phone 7.5, and partially supported on Silverlight (see this blog post for details).

Thanks for all the feedback we’ve received. We’d love to hear how you like the new version!

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
  • Hi, anyone having the following exception when simply trying to connect to a web service:

    'iso-8859-1' is not a supported encoding name.

    Parameter name: name

    Client is using Silverlight 5 and web service is using Web API 2.0. Performing a simple GetStringAsync gives me this exception. I don't specify an encoding but I don't see a request event come out of the client using Fiddler.

Page 3 of 3 (31 items) 123