Get /httpclient/rtm – 200 OK

Get /httpclient/rtm – 200 OK

Rate This
  • Comments 23

As promised in our last blog post we’re releasing Microsoft.Net.Http as a stable NuGet package today. Yep, that’s right: You can finally start using the portable HttpClient 2.1 in production!

As we’ve discussed in previous blog posts, HttpClient is a modern networking API which makes it easy to access any resource exposed through HTTP. The HttpClient API has been available in some versions of .NET for a while now. This NuGet package makes a standard set of HttpClient APIs available across a wider array of platforms, including Windows Phone 7.5 and higher, .NET Framework 4.0 and higher, and Windows Store. This enables you to share more .NET code across these platforms.

This package also addresses one of the top User Voice requests for .NET: providing an HttpClient implementation for Portable Class Libraries (and therefore also on Windows Phone 8).

We closed this request when we posted the preview of the new HttpClient back in February. Now, with the release of a stable version, we’re excited that you now have a high-quality implementation to use and build on in your .NET projects.

This package requires Visual Studio 2010 or Visual Studio 2012, and NuGet package manager 2.5 or higher.

Changes from RC

We haven’t changed much since last week's release candidate (RC), but this is by-design. For our NuGet packages, feature work is first released in beta builds only. Once we think we matured a feature enough (based on internal testing as well as customer feedback), we release an RC. If there aren’t any major bugs, we turn (generally the same) bits into an RTM, which NuGet calls a stable release. This process helps ensure that we ship high-quality components.

We did make some very minor changes to our package metadata:

  1. To make the package easier to recognize as an official Microsoft component, we prefixed it with “Microsoft”.
  2. To improve search results, we added tags (e.g., “HTTP” and “REST”).

What’s next for HttpClient?

As I explained in my last blog post, the current release doesn’t include support for automatic decompression. One of our readers commented that each time a web request is issued without gzip support, it hurts baby seals.

We know automatic compression is an important feature for you, and we care deeply about the health of baby seals, so we are working on a portable compression library that provides this feature. Our plan is to ship a beta release of HttpClient 2.2 that includes this library very soon. As a reminder, here is our tentative release schedule:

  1. Mid-June: Beta of HttpClient 2.2 with automatic decompression
  2. End of June: RC of HttpClient 2.2 with automatic decompression
  3. Around July (depending on feedback): RTM of HttpClient 2.2 with automatic decompression

Community support for automatic compression

Until we release a stable version of automatic decompression that you can use in production, there are some alternatives you may want to consider. (Please note this isn’t intended to be a complete list. If you’ve developed a similar feature, let us know by posting a comment below.)

  1. Morten Nielsen, a Microsoft Valued Professional (MVP), has provided an implementation of HttpClientHandler that has support for gzip compression. You can find the source code here:

    https://gist.github.com/dotMorten/4981198

  2. Robert McLaws created a derived project and packaged it up as a NuGet package. You can install his NuGet package either via the package manager console:

                    Install-Package HttpClient.Compression –Pre

    or by searching for HttpClient.Compression in the NuGet Package Manager dialog. At the time of this writing, HttpClient.Compression wasn’t available as a stable NuGet package, because the stable version of our HttpClient wasn’t released yet. I’m sure it will get updated very soon, though.

Summary

HttpClient 2.1 is now available as a stable release on NuGet. The license allows its use in production and unblocks third parties from building stable NuGet components on top of it.

You can expect a beta release of HttpClient 2.2 with support for automatic decompression very soon. Meanwhile, help protect baby seals by using one of community libraries we linked to above. If there are other community libraries available, please let us know in the comments section!

Leave a Comment
  • Please add 3 and 7 and type the answer here:
  • Post
  • Nice work! +bonus points for continued transparency.

  • Congragulations guys. A request for 2.2: can you see if you can support _streaming_ decompression (ie. don't load the whole response into memory first). Morten's implementation does this and it causes havok in background agents on WP7 due to the memory used.

  • Thanks guys for the shoutout! Just thought I'd mention a couple things: 1) HttpClient.Compression is a PCL that supports GZIP and DEFLATE, whereas Morton's version is not a PCL and just supports GZIP. Also, I've released version 1.1 RTM that is compiled against this release. You can get it from NuGet or download the source from GitHub. Fantastic work guys, thanks for this! And please, keep putting out more 4.5 stuff as cross-platform PCLs :).

  • Hey Richard,

    My implementation of HttpClient.Compression is a little different than Morten's, specifically it does not call LoadIntoBufferAsync() first. Can you please check and see if it gives you the desired behavior? If not, please open a ticket on GitHub here: github.com/.../HttpClient.Compression and I'll take a look at what can be done.

  • Robert: It's not PCL for several reasons:

    1. Quite frankly I didn't see the need since all other platforms than WinPhone has GZIP support.

    2. I rely on the built-in decompression to avoid the license issues that ZLip.Portable library has since it's based on DotNetZip and this library's license isn't complete kosher.

  • Richard Szalay,

    For information about the specifics of gzip support used by Morten's approach (specifically, why it's necessary to load the entire response into memory), please see my post:

    blogs.msdn.com/.../quot-if-i-have-seen-further-it-is-by-standing-on-the-shoulders-of-giants-quot-an-alternate-implementation-of-http-gzip-decompression-for-windows-phone.aspx

  • @Robert - Based on my previous readthroughs of DotNetZip's GZipStream, your implementation should be fine.

    The only things I'm not sure of is the license and how HttpContent.SerializeToStreamAsync is somehow used to stream content.

    @David - I've actually read your post in the past (in addition to reading through the source for Morton's library), so I understand _why_ it loads everything into memory, but that still doesn't resolve the WP7 agent issue.

  • @Robert - Scratch that. Turns out that HttpContent always buffers the response into memory, even if you use ReadAsStreamAsync (which returns a MemoryStream), so it's not really any use for my situation anyway.

  • Same problem as with the RC version - I don't see the RTM version as available update in NuGet in my WP8 project. Is there a problem in NuGet cache or something?

  • @Richard  To stop HttpClient from automatically buffering a response stream you need to call SendAsync with the HttpCompletionOptions.ResponseHeadersRead  

  • Your Software is bad and you should feel bad about it.

  • Every time CacheControl and ETag headers are not respected and used, a kitten gets run over. WILL SOMEONE FOR THE LOVE OF GOD PLEASE THINK OF THE KITTENS!

  • @Morten: Are you talking about phone's cache implementation not honoring these?  If so that's good feedback for wpdev.uservoice.com/.../110705-dev-platform.

  • Nitpicking, but shouldn't it at this point be named RTN (Release To NuGet) or RTSN (Release To Stable NuGet)?

    Great to see a RTM release for the portable version.

  • Morten,

    There shouldn't be any licensing issues with the Zlib.Portable library I ported from DotNetZip, because at its core it is the same library that Microsoft ships with the .NET Framework, they just use the native version of Zlib from http://zlib.net instead. The license used by Zlib is different than DotNetZip and considerably more permissive.

    My only other option to support Deflate was to use a version of System.IO.Compression.dll that a major consulting firm posted in a tweet about a year ago, but I could not verify its origins or licensing and therefore had to go a different route. :)

Page 1 of 2 (23 items) 12