HttpClient 2.2 is now stable

HttpClient 2.2 is now stable

Rate This
  • Comments 32

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 |
var httpClient = new HttpClient(handler);
var str = await httpClient.GetStringAsync("");

The request then provides the additional Accept-Encoding header:

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:


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.


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 7 and 1 and type the answer here:
  • Post
  • Amazing, thanks guys.

  • Getting this error atm:

    Error 1 The type 'System.Net.CookieContainer' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net, Version=, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'.

    Error 2 'System.Net.CookieContainer' does not contain a definition for 'Add' and no extension method 'Add' accepting a first argument of type 'System.Net.CookieContainer' could be found (are you missing a using directive or an assembly reference?)

    I've tried reparing vs2012 update3 with no luck.

    I've tried msiexec.exe /fomus {6A6F1B4D-1BCE-3703-93D8-4494FB7F1280} with no luck (doesnt work for me).


  • @Sproa: It seems the command we provided is outdated. Can you try to repair the installation via Programs and Features (Add or remove programs)? In essence, select the appropriate VS installation/highest VS update and click on "Change". In the VS setup click the "Repair" button.

  • @Immo Landwerth

    I tried the repair on the vs2012 udpate 3 as well (see my previous post) and that did not help. Can add I've also installed the 2013 preview. Could that be the culprit?

  • Now when Windows 8.1 preview is available with new features in HttpClient, do you plan to backport these features to HttpClient NuGet package as well?

  • @Sproa: If the problem still exists please send a mail to immol at microsoft dot com. I'll put you in touch with people that can troubleshoot this issue.

    @Martin: The WinRT version of HttpClient is tied to Windows 8.1 while our NuGet package supports a wider range of platforms. We are thinking of ways to align the two without losing creating a platform dependency in all cases.

  • Does the HttpClient 2.2 handle custom ssl certificates without throwing a 404 not found for WP7/8?


  • @AsurionDevelopers: HttpClient uses the phone's networking stack and thus has the same limitations. So I'm afraid the answer is no.

  • @Immo @Sproa Did you find a solution to the "assembly not referenced" problem? I too side-installed VS2013 thinking it would be safe, but I cannot longer work on my Windows Phone project due this week! I've tried uninstalling VS2013, repairing VS2012, the WP8 SDK and VS2012 Update 3, but nothing seems to help. Any ideas are welcome.

  • @Mauricio DIAZ ORLICH

    No I haven't.  I am still waiting to hear back from techs at Microsoft that was put in touch with me.

  • Wow, this piece of software helps me a lot. Thanks!

  • Is there any way you can include in the response headers of .PostAsync() and .SendAsync() the "set-cookies" headers? In windows phone there is a know problem with httponly cookies that are not accessible through cookiecontainer. A simple solution will be to get the cookies in headers and forget the cookiecontainer implementation  and process these myself.

    I know I can pass the cookiecontainer in subsequent request, but the problem is that I´m "fighting" with lot of different servers that does not send the cookies in correct RFC format, so cookiecontainer miss these and this solution does not work for me. Also in WP there is no reflection support so I can not bypass the cookiecontainer to extract these cookies.

    Any hint on this?

  • Looks like there is some problem with HttpClient Lib on Win Phone 8/7 with Content-Length header value

    It does not give the content-length header value when doing a Head request. Content-Length is always "0".

    Checked with Fidler and there Content-Length is there with a proper value.

    Here is code in WinPhone 8 [Note: The same code works for Windows 8 store apps]

    Uri uri = new Uri("");

               HttpClient cc = new HttpClient();

               var request = new HttpRequestMessage(HttpMethod.Head, uri);

               var response = await cc.SendAsync(request);

    Response from Fidler when i configured Fidler for Windows Phone Emulator

    HTTP/1.1 200 OK

    Content-Length: 138139

    Content-Type: application/octet-stream

    Last-Modified: Tue, 07 Apr 2009 06:50:49 GMT

    Accept-Ranges: bytes

    ETag: "8f1c882f4db7c91:0"

    Server: Microsoft-IIS/8.0

    Content-Disposition: attachment

    Date: Thu, 07 Nov 2013 05:39:40 GMT

    Connection: keep-alive

    Have any one faced this before ? Is there any workaround for this.

  • @Saurabh: indeed this appears to be an issue on Phone.  We'll look into a fix in our next release.  Thanks for reporting.  For now you can workaround this by sending the HEAD with HttpWebRequest and looking at the Content-Length value in the Headers collection of the response (don't use the ContentLength property, as this will be incorrect and is the source of this bug).

  • Hi, I posted a bug report of trouble I am having when HttpClient makes http requests to a bad url:

Page 2 of 3 (32 items) 123