This project is read-only.

Asynchronous HttpClient?

Topics: Web Api
Aug 4, 2011 at 7:26 PM
Edited Aug 4, 2011 at 7:46 PM

Hello -

After watching some of the WCF Web API videos available, I got the impression that HttpClient is a closer-to-the-metal re-implementation of HttpWebRequest with better standards support. However, I see in Reflector that it's just a wrapper around HttpWebRequest (channeled via HttpClientChannel).

One of the problems that I have with HttpWebRequest is that it does not provide true asynchronous behavior (DNS/proxy lookups and the actual socket connection are done synchronously). Thus, it does not play well with the Async CTP. The rest of the WCF Web APIs seem to be designed to work well with Async CTP (using Tasks).

1) Will HttpClientChannel eventually stand on its own with true async support, leaving HttpWebRequest as the "old way" of doing things?
2) If not, then will HttpWebRequest be modified to allow true asynchronous behavior?

I suppose I could create my own HttpMessageChannel, but that would be a pain.


Aug 5, 2011 at 4:35 PM

I'd love to see a reply to this as well.  I'm currently planning a website making heavy use of REST services and async is a concern for us.

Aug 9, 2011 at 10:26 PM

I'm in the same boat as SiggiG - I'm writing a web service that makes heavy use of REST services. A partially-async HttpClient limits our scalability.

According to the Async team, there are not currently plans to re-write BeginGetRequestStream or BeginGetResponse. So that means (2) is not on the table.

We may not see (1), either. What we really need is a new HttpClient that is written to the HTTP spec with full async support, and it's not likely that we'll get it. It's quite a bit of work for a little bit of scalability for a small percentage of end-user applications. From Microsoft's point of view, I doubt it would be worth it.

As the "open web" grows, this problem will become more and more common. Maybe someday we'll get an async HttpClient.