WebClient vs. HttpWebRequest/HttpWebResponse

Question

It seems to me that most of what can be accomplished with HttpWebRequest/Response can also be accomplished with the WebClient class. I read somewhere that WebClient is a high-level wrapper for WebRequest/Response.
So far, I can't see anything that can be accomplished with HttpWebRequest/Response that can not be accomplished with WebClient, nor where HttpWebRequest/Response will give you more "fine-grained" control.

When should I use WebClient and when HttpWebRequest/Response? (Obviously, HttpWebRequest/Response are HTTP specific.)

If HttpWebRequest/Response are lower level then WebClient, what can I accomplish with HttpWebRequest/Response that I cannot accomplish with WebClient?

score 91 · Accepted Answer · answered Nov 07 '09 at 21:01

91

Using HttpWebRequest gives you more control on the request. You can set cookies, headers, protocol, etc... In the response, you can also retrieve the cookies and headers

answered Nov 07 '09 at 21:01

Thomas Levesque

286,951
70
623
758

14

Thomas, still not convinced... WebClient has a Headers property, you can retrieve the cookie like this: String cookie = webClient.ResponseHeaders(“Set-Cookie”) and set it: webClient.Headers.Add("Cookie", "CommunityServer-UserCookie…"); – Dan Nov 07 '09 at 21:23
2

So you have to handle the cookies manually... not very convenient. I agree that in most cases, WebClient is OK, and actually better than HttpWebRequest because it's simpler to use, but in some cases you're better off using HttpWebRequest – Thomas Levesque Nov 07 '09 at 22:10
15

Using HttpWebRequest you can define a timeout. In WebClient, that's impossible. – ripper234 Nov 11 '10 at 06:06
15

@ripper234, actually it *is* possible: you just have to inherit WebClient and override GetWebRequest to customize the HttpWebRequest – Thomas Levesque Nov 11 '10 at 14:39
1

Hmm, interesting - I never thought of that! – ripper234 Nov 11 '10 at 17:49
16

@ThomasLevesque if you are inheriting webclient and overriding the webrequest, it seems pointless to use the webclient... – Hagai L Feb 20 '12 at 16:25
6

@HagaiL, I disagree... You don't have to create the whole request manually, you can use `base.GetWebRequest` to create it and then customize just what you want – Thomas Levesque Feb 20 '12 at 16:48

score 57 · Answer 2 · edited Dec 30 '10 at 17:54

57

HttpWebRequest exposes a lot more stuff that allows you fine grained protocol control, for eg: whether you want to use Keep-Alive, what connection pool to use, whether to buffer writes or not, etc.

WebClient does not expose all of those (although you can subclass from WebClient and getaccess to the underlying Request object).

WebClient is useful for those situations where you just want to do an operation (eg: POST/GET/Form upload) and cant be bothered to create and manage the HttpWebRequest, RequestStream, HttpWebResponse, and response stream.

edited Dec 30 '10 at 17:54

JYelton

35,664
27
132
191

answered Nov 08 '09 at 16:14

feroze

7,380
7
40
57

13

Also, there is one more thing that I forgot to mention. WebClient is a Component object, whereas HttpWebRequest is not. What does that mean? Well, if you are using VisualStudio to build a GUI app, then you can drag/drop WebClient component on your form and use it to issue requests to HTTP/FTP etc servers. – feroze Nov 11 '09 at 01:50

score 14 · Answer 3 · answered Nov 07 '09 at 21:02

14

From Tim Heuer's blog - http://timheuer.com/blog/archive/2008/03/14/calling-web-services-with-silverlight-2.aspx

Instead in Silverlight you'll want to use WebClient or HttpWebRequest. What's the difference? Here's the timheuer version. WebClient is a simpler implementation doing GET requests really easily and get a response stream. HttpWebRequest is great for when you need a bit more granular control over the request, need to send headers or other customizations.

answered Nov 07 '09 at 21:02

Benjamin Cox

6,090
21
19

7

WebClient also allows POST, with UploadString, UploadData and UploadFile – Thomas Levesque Nov 07 '09 at 21:04
@ThomasLevesque Is there a newer version of the classes today? I see that this discussion is a bit, hmm... aged... – Konrad Viltersten Dec 04 '15 at 09:46
@KonradViltersten, I don't think there's been much change to the WebClient class. For new apps I suggest you use HttpClient instead, which is also very easy to use and much more flexible. – Thomas Levesque Dec 04 '15 at 10:31
1

@ThomasLevesque Right, **that** was the one I was thinking about. I recalled *http* as the difference in the class name and got mislead by *Http...* part. Now I'm back on the right track. Thanks! – Konrad Viltersten Dec 04 '15 at 10:35

score 13 · Answer 4 · answered Nov 23 '11 at 04:45

13

The WebClient class runs on the user interface thread, so the user interface is not responsive while data is being downloaded from the Internet. On the other hand, the HttpWebRequest class does not block the user interface thread, and your application is responsive. So, in apps where a large amount of data is to be downloaded from the Internet or if the source of the data is slow to access, you should use the HttpWebRequest class; in all other cases, you should use the WebClient class.

answered Nov 23 '11 at 04:45

Baaziz

181
1
2

1

The opposite is true on WP7. HttpWebRequest marshals back to the UI thread in Mango, causing me no end of grief right now. Grrr – Cameron MacFarland Nov 25 '11 at 06:04
6

WebClient supports asynchronous methods as well. – CyberMonk May 09 '13 at 11:21

score 6 · Answer 5 · answered Feb 09 '13 at 02:37

6

Another disadvantage of WebClient is it ignores the HTTP ContentType's charset value when you use it to get the response text. You have to explicitly set the encoding via the Encoding property.

answered Feb 09 '13 at 02:37

Sam

40,644
36
176
219

This is a good point; and it's not just a matter of setting the `Encoding` - you can't *know* the encoding until after the request, so the WebClient api makes it very unlikely you're going to be able to properly download a string in an unknown encoding. – Eamon Nerbonne Oct 21 '15 at 21:27

score 5 · Answer 6 · answered Jun 01 '12 at 01:30

5

One more thing HttpWebrquest allows you compression but he Net.WebClient class doesn't support HTTP compression

answered Jun 01 '12 at 01:30

Zain Ali

15,535
14
95
108

3

Just like all the other examples of WebClient hiding some details, this can be fixed by subclassing WebClient and overriding `GetWebRequest`. In this case, you simply [tweak the underlying `HttpWebRequest.AutomaticDecompressiong` property](http://stackoverflow.com/a/4914874/48700)). – patridge Oct 11 '12 at 15:53

score 5 · Answer 7 · answered Jan 27 '15 at 19:28

5

The "HtttpWebRequest" is obsolete in .NET 4.5. Now, this class is internal only.

answered Jan 27 '15 at 19:28

Julio Spader

349
4
7

2

Indeed. Use `WebRequest` instead. – silkfire Sep 01 '15 at 21:34
2

The class is not obsolete, the constructors are. And the class is not internal, it is still public. – user247702 Mar 08 '18 at 15:56

score 2 · Answer 8 · answered Apr 30 '10 at 07:08

2

One example: Posting data and getting back processed data in one request/response cycle seems to be impossible with WebClient, but you can do that with HtttpWebRequest.

answered Apr 30 '10 at 07:08

synergetic

7,756
8
65
106

2

Simply use WebClient.UploadString or WebClient.UploadData to perform a POST and get back a response string or byte array. – samjudson Jul 11 '11 at 13:42
2

To clarify, the return value of the UploadString is a string and the return value of the UploadData method is a byte array. – Norman H Sep 23 '11 at 17:18

WebClient vs. HttpWebRequest/HttpWebResponse

8 Answers8

Linked

Related