[DrJokepu]

Just out of curiosity, what's so awful about WebRequest? I've been using it for years for various things and never really had a problem with it.

[johns]

  - It's too low level for quick stuff
  - It handles HTTP basic auth wrong
  - It throws an exception, AN EXCEPTION, for any response that isn't 2xx
  - Async is an ugly mess
  - In love with streams
  - Horribly inconsistent across framework profiles
  - ServicePointManager.Expect100Continue
  - Inconsistent header handling and restrictions
  - Terrible cookie API

[burke_holland]

I think it's fine for simple scenarios (i.e. plain GET), but it breaks down in a hurry and the fact that you have to read out of the response stream is real overhead.

[masklinn]

> I think it's fine for simple scenarios (i.e. plain GET)

So's python's urllib2, the point of `request` is that as soon as you go even slightly beyond very basic GET and POST, it breaks down quickly in a horrible mess.

[mattmanser]

It's not fine for a plain GET, it's awful.

I'm still surprised every time I use it that they've not released a modern library for it in .Net.

[ArbitraryLimits]

The async handling was the deal breaker for me. I gritted my teeth through the other stuff but finally gave up at that point.

[glassx]

I'm not your parent poster but I personally dislike that you have to instantiate a separated Response object, and that you have to fetch a stream, even for tiny responses. In those Python/Ruby frameworks it's just one line. I always end up writing a wrapper just to change it.

And this one is a pet peeve, but I hate that verbose stateful OO idiom where you instantiate an object (with a factory) and then use setters to change properties, instead of setting it all in a single command. I don't know if other .NET HTTP libraries change that, though...