HttpWebRequest and IDisposable

[Mark Rae]

Hi,

The following code works:

HttpWebRequest objRequest = null;
try
{
HttpWebRequest objRequest =
(HttpWebRequest )WebRequest.Cre ate("http://www.microsoft.c om");
using (HttpWebRespons e objResponse =
(HttpWebRespons e)objRequest.Ge tResponse())
{
// do something...
}
}
catch
{
throw;
}
finally
{
if (objWebRequest != null)
{
objWebRequest = null;
}
}

However, the following code doesn't work:

using (HttpWebRequest objRequest =
(HttpWebRequest )WebRequest.Cre ate("http://www.microsoft.c om"))
{
using (HttpWebRespons e objResponse =
(HttpWebRespons e)objRequest.Ge tResponse())
{
// do something...
}
}

because HttpWebRequest is not implicitly convertible to IDisposable.

I'm curious to know if there is a way to use HttpWebRequest with the
"using" - just for my own interest, really...

Any assistance gratefully received.

Mark

[Marc Gravell]

(Following relates to all general variable usage; not specifically to
web-request)

Well, what do you think your code does?

catch {
throw;
}

Does nothing, as it would have been thrown anyway... so that leaves the
finally:

finally
{
if (objWebRequest != null)
{
objWebRequest = null;
}
}

Interestingly, because you read the variable (in the test), this
technically *extends* the lifetime of the variable. Otherwise it would
be eligible for collection earlier. I guess it all depends on whether
objWebRequest is a field (scoped by the class) or a variable (scoped by
the method). If a field, fine: just remove the catch; if a variable,
then just let it go out of scope; it will actually be avaiable for GC
as soon as your last "read". In a garbage collected world, the "using"
and "finally" patterns are mainly for timely disposal of resources. The
above looks more like COM / VB6, but you don't need this with C#
variables.

Marc

[Dave Sexton]

Hi Mark,

<snip>

However, the following code doesn't work:

using (HttpWebRequest objRequest =
(HttpWebRequest )WebRequest.Cre ate("http://www.microsoft.c om"))
{
using (HttpWebRespons e objResponse =
(HttpWebRespons e)objRequest.Ge tResponse())
{
// do something...
}
}

because HttpWebRequest is not implicitly convertible to IDisposable.

I'm curious to know if there is a way to use HttpWebRequest with the
"using" - just for my own interest, really...

I think it's strange that WebRequest doesn't implement IDisposable since it
can create a Stream, which does implement IDisposable. Unfortunately, there
is no way for you to use the "using" statement with this class, although you
probably shouldn't worry about that anyway.

Instead, you may want to use WebClient, which is IDisposable:

using (WebClient client = new WebClient())
{
using (Stream stream = client.OpenRead (url))
{
// etc.
}
}

--
Dave Sexton

[Mark Rae]

"Marc Gravell" <ma**********@g mail.comwrote in message
news:11******** **************@ n67g2000cwd.goo glegroups.com.. .

I guess it all depends on whether objWebRequest is a field
(scoped by the class) or a variable (scoped by the method).

It has nothing whatsoever to do with that at all - did you actually*read* my
original post...?

Dave Sexton understood it and replied accordingly - you might want to have a
read at his...

[Mark Rae]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ev******** ******@TK2MSFTN GP04.phx.gbl...

I think it's strange that WebRequest doesn't implement IDisposable since
it can create a Stream, which does implement IDisposable.

I was / am of that opinion too - hence my original post...

Unfortunately, there is no way for you to use the "using" statement with
this class,

That's what I thought - thanks for the clarification.

although you probably shouldn't worry about that anyway.

Indeed not - like I said, I merely posted the question for my own interest,
not because I had some burning need to use "using" with HttpWebRequest. ..
:-)

I find that by now, after quite a few years of working with the .NET
Framework, most of it makes reasonably intuitive sense, so when I come
across something like this which seems unusual, I'm naturally curious about
it...

Instead, you may want to use WebClient, which is IDisposable:

using (WebClient client = new WebClient())
{
using (Stream stream = client.OpenRead (url))
{
// etc.
}
}

That seems like a good suggestion - so, am I right in thinking that
WebClient performs the functions of both HttpWebRequest and
HttpWebResponse ...?

[Peter Bromberg [C# MVP]]

Yes,
WebClient does, but it's a wrapper over the whole mechanism designed to
simplify and doesn't provide access to all the lower-level "stuff" that's in
HttpWebRequest and HttpWebResponse .
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Mark Rae" wrote:

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ev******** ******@TK2MSFTN GP04.phx.gbl...

I think it's strange that WebRequest doesn't implement IDisposable since
it can create a Stream, which does implement IDisposable.

I was / am of that opinion too - hence my original post...

Unfortunately, there is no way for you to use the "using" statement with
this class,

That's what I thought - thanks for the clarification.

although you probably shouldn't worry about that anyway.

Indeed not - like I said, I merely posted the question for my own interest,
not because I had some burning need to use "using" with HttpWebRequest. ..
:-)

I find that by now, after quite a few years of working with the .NET
Framework, most of it makes reasonably intuitive sense, so when I come
across something like this which seems unusual, I'm naturally curious about
it...

Instead, you may want to use WebClient, which is IDisposable:

using (WebClient client = new WebClient())
{
using (Stream stream = client.OpenRead (url))
{
// etc.
}
}

That seems like a good suggestion - so, am I right in thinking that
WebClient performs the functions of both HttpWebRequest and
HttpWebResponse ...?

[Mark Rae]

"Peter Bromberg [C# MVP]" <pb*******@yaho o.nospammin.com wrote in message
news:2B******** *************** ***********@mic rosoft.com...

WebClient does, but it's a wrapper over the whole mechanism designed to
simplify and doesn't provide access to all the lower-level "stuff" that's
in
HttpWebRequest and HttpWebResponse .

Thanks for that.

[Marc Gravell]

did you actually*read* my original post...?
Yes thanks very much for asking. You said (essentially) "this works". I
was observing that it may well work, but it achieves nothing.

Marc

[Marc Gravell]

Additional:

I think it's strange that WebRequest doesn't implement IDisposable since it

can create a Stream, which does implement IDisposable.

Just because something is capable of creating and returning an
IDisposable object does not imply that it is *itself* IDisposable. Any
objects created from this class should, of course, be disposed
correctly.
I have run reflector over WebClient, and even in this case it only
picks up IDisposable as an arftifact of the base Component class - it
doesn't actually provide any Dispose() logic of its own. Of course, I
would still be "using" WebClient.

The *very* curious thing (to turn this all on its head) is that
HttpWebRequest *does* have some IDisposable fields - a few internal
streams and a timer (possibly more; stopped looking). Unless these are
all guaranteed to be cleaned up before leaving encapsulating methods,
you would *expect* HttpWebRequest to be disposable, and hence the
original "why doesn't this work" would be completely valid (and
WebClient would have something interesting to do in *its* Dispose()
method). All very interesting.

My original point, however, still stands: setting something to null is
a very different beast to Dispose()ing it; if it isn't IDisposable,
then it doesn't need to be Dispose()d, so you can't be "using" it.

Marc

[Mark Rae]

"Marc Gravell" <ma**********@g mail.comwrote in message
news:11******** **************@ n67g2000cwd.goo glegroups.com.. .

setting something to null is a very different beast to Dispose()ing it;

That's right.

if it isn't IDisposable, then it doesn't need to be Dispose()d,

Er, surely if it isn't IDisposable, then it *can't* be Dispose()d,
irrespective of whether it needs to be or not...???

so you can't be "using" it.

Er, right again... And precisely because HttpWebRequest isn't IDisposable, I
wasn't "using" it, hence the reason I was explicitly setting it to null in
finally{...}

My original post centred on my surprise that HttpWebRequest *isn't*
IDisposable...