New features

To address some of the platform differences in a portable fashion, we’ve added new capability APIs.

HttpClientHandler.SupportsUseProxy(): The existing HttpClientHandler.SupportsProxy property indicates whether both the UseProxy property and the Proxy property are supported. This created an issue because some platforms (for example, Windows Phone) don’t allow you to configure a proxy explicitly. However, Windows Phone lets you control whether the machine wide proxy should be used. To model this behavior, we added the HttpClientHandler.SupportsUseProxy() extension method. For some platforms that don’t support both, such as Windows Phone, the SupportsProxy property will continue to return false, but the SupportsUseProxy() method will return true.

HttpClientHandler.SupportsAllowAutoRedirect(): The HttpClientHandler.SupportsRedirectConfiguration property had a similar issue: It controls whether both the AllowAutoRedirect and the MaxAutomaticRedirections properties are supported. Windows Phone doesn’t support specifying the maximum number of automatic redirections, but it does support redirection. For that reason, we added the HttpClientHandler.SupportsAllowAutoRedirect() extension method.

In case you are wondering why we added extension methods instead of regular properties: Some of the platforms that Microsoft.Net.Http supports already provide the HttpClientHandler class, which is used on those platforms. Since we can’t modify the built-in version of the properties directly, we added extension methods that ship in a separate assembly with the NuGet package.

Bug fixes

All bug fixes are listed in the release notes. In this post, I’d like to highlight just one:

Issue: When consuming a portable class library that depends on HttpClient from a Windows Store application, the app can crash with a MissingMethodException.

We’ve fixed this bug by using the technique we explained in our blog post about Microsoft.Bcl.Async: We ensure during the build that the application has a reference to the NuGet package.

Future directions

This RC doesn’t include support for the HttpClientHandler.AutomaticDecompression property. Many of you have asked for this support, and we certainly haven’t ignored it or forgotten about it. In fact, our original plan was to ship another preview with support for automatic decompression, and then ship an RTM version a few weeks later. So why did we change our minds about it?

We had two options:

Block the release of HttpClient until automatic decompression is ready.

Ship an interim release of HttpClient that doesn’t have automatic decompression but is marked as a stable NuGet release and comes with a license that allows usage in production.

We decided to go with the second option, because we believe it delivers functionality sooner to our customers. After all, that’s why we ship on NuGet, and we hope you agree.

Let’s recap why our team is investing so much in releasing components via NuGet. The reason is twofold:

First, it allows bridging differences in functionality between platforms we already shipped. A good example is HttpClient, and also includes the support for the async and await keywords. Shipping features out of band also enables us to ship new functionality for multiple platforms via a single portable class library, without having to wait for any of the platforms to add that functionality.

Second, our goal is to strengthen the feedback loop with you, our customers. In the past, we’ve shipped “big” betas, like a beta of the entire .NET Framework. This approach certainly has some advantages, but we’ve seen issues with it as well. The biggest downside is that “big” betas are pretty expensive to ship and are typically very close to RTM, which, in turn, means that we can’t make impactful changes anymore. In fact, we have to turn down a large number of the bug reports we get in “big” betas, either because they affect a relatively small number of customers or because fixing the bugs would place the RTM release at risk. We’re certainly not the first company running into this problem; there is an entire agile software development movement in our industry that focuses on this. I don’t want to go into a philosophical discussion about agile methodologies, but it’s pretty hard to disagree that shipping early and often helps with feedback loop issues.

A good example where we use your feedback quite heavily is in the previews of immutable collections; in contrast to “big” betas, we were able to change the design of the APIs when we believe that’s the correct approach.

Unfortunately, shipping a constant stream of previews isn’t necessarily a helpful solution in all scenarios. On certain platforms, such as the .NET Framework 4.5 and Windows Store, HttpClient is already available as a fully supported, RTM-quality component. For that reason, we can offer a preview of HttpClient only for Windows Phone today.

Here are our tentative plans for future NuGet releases of HttpClient:

Today: RC of HttpClient 2.1.

Wednesday 5/29: RTM of HttpClient 2.1. Yep, it’s only a week away now, but it entirely depends on your feedback. If we find substantial issues, we might change the release date.

Mid-June: Beta of HttpClient 2.2 with automatic decompression

End of June: RC of HttpClient 2.2 with automatic decompression

Around July (depending on feedback): RTM of HttpClient 2.2 with automatic decompression

Summary

We released an RC version of the Microsoft.Net.Http NuGet package. We expect this to be the last preview of HttpClient before we ship an RTM. Please provide feedback if you find any issues.

Of course, we’d also love to hear from you if everything just works. After all, we’re happy if you’re happy!

If you need to add compression to Windows Phone (which you do!!! Baby seals are clubbed to death each time a webrequest is done without gzip support), you can use my gist here to add a custom HttpHandler with compression support here:

But I'm still wondering if you're planning to create similar package for StorageFile/StorageFolder API? I've discovered to my great surprise, that I cannot use StorageFIle API even in PCL targeting Windows 8 and WP8 when both of these platforms has it.

@kris: The HttpClient we just released provides a portable version that can be used across several platforms, including from Portable Class Libraries (PCL). On platforms that already support it, we'll use the in-box version. On platforms that don't we use the one we include in the NuGet package.

@John: Yes, you can use our NuGet package on .NET 4. In fact the downlevel support is one of it's primary goals. In general, the consumption should work from Visual Studio 2010, although it might be quite painful given that the compilers don't support the async/await keywords.

@Morten: Regarding ReadByte(): Thanks, we'll look into it. Regarding compression: I hope that baby seals aren't impacted by this but we do understand that the lack of compression is a major issue. That's why we work on it right now 🙂

@Necroman: The reason it's not avaialble is because Portable Class Libraries doesn't support WinRT yet. However, we are thinking about if and how we could enable this. For the time being, we recommend factoring storage out by using, for example, a DI container.

@David: I guess you're hinting at the fact that this NuGet package doens't support Mono. The definition of "portable" we are using is the support of Portable Class Libraries (PCL). Portable in that context means that the binary itself is portable between different versions of the .NET platform (for example, the full framework, Silverlight, Windows Phone, and Windows Store).

Wouldn't it be possible to emulate webproxy on the platforms that don't support proxy globally? I have been looking for such an option on Windows Phone 8 recently but couldn't find any library that would support this.

Not sure, if it's a bug or some kind of cache problem but in the day this article was posted I checked my project that is using the previous 2.1.3 version of HttpClient and no update was shown in NuGet to version 2.1.6. I had to manually uninstall the beta and install again the RC version.

I had a sync function on winrt that worked great, so I installed httpclient portable to use this function on Windows phone 8. But my problema is that when i call httpclient.SendAsync I got 404 notfound error. But this can't be posible, as the url is fine, and if I dont send any content it works great. I think that the bug can be that i try to send a picture (about 1,2 mb). In my winrt App i can use the same function to send pictures without any problems.

@Morten & @HermitDave: This change as intentional. We enabled the streaming scenario by turning off AllowReadStreamBuffering on our underlying HttpWebRequest. HttpClient defines a set of APIs that let you more granularly control the buffering behavior (HttpCompletionOption & HttpResponseMessae.ReadAs*Async & LoadIntoBufferAsync). It was a bug in Beta that setting HttpCompletionOption.ResponseHeadersRead had no effect (because we were telling phone to buffer the entire request), now that it is fixed it exposes this problem. For folks that run into this you can either pass in HttpCompletionOption.ResponseContentRead when you make the request or await response.Content.LoadIntoBufferAsync().

httpclient on WP8 under low connectivity (2G) gives me a lot of problems, is there any way to increase the waiting time? It gives me 404 error (I know that this error is not very descriptive) really fast. I tried to use a Windows Phone Component in C++ with the same results.