Question

We have a large library that makes a lot of HTTP calls using HttpWebRequest to get data. Rewriting this library to make use of async calls with the HTTPClient would be a bear. So, I was wondering if I could create async controllers that use a taskfactory to call into our library and whether the calls that are ultimately made via the WebClient would be asynch or they would still be synch. Are there any problems/side-effects I might cause by trying to mix async with the old HttpWebRequest?

Answer 1

If I’m understanding what you’re proposing the answer is: no, changing the services the client talks to to be async would not help. The client would still block a CPU thread while the I/O is outstanding with the server, whether the server is async or not.

There’s no reason to switch away from HttpWebRequest. You can use TaskFactory::FromAsync in .NET 4.0 to call HttpWebRequest::BeginGetResponse. That looks something like this:

WebRequest myWebRequest = WebRequest.Create("http://www.stackoverflow.com");

Task<WebResponse> getResponseTask = Task<WebResponse>.Factory.FromAsync(
                                                myWebRequest.BeginGetResponse,
                                                myWebRequest.EndGetResponse,
                                                null);

getResponseTask.ContinueWith(getResponseAntecedent =>
{
   WebResponse webResponse = getResponseAntecedent.Result;

   Stream webResponseStream = webResponse.GetResponseStream();

   // read from stream async too... eventually dispose of it
});

In .NET 4.5 you can still continue to use HttpWebRequest and use the new GetResponseAsync method with the new await features in C# to make life a heck of a lot easier:

WebRequest myWebRequest = WebRequest.Create("http://www.stackoverflow.com");

using(WebResponse webResponse = await myWebRequest.GetResponseAsync())
using(Stream webResponseStream = webResponse.GetResponseStream())
{
     // read from stream async, etc.
}