Will the "Underlying connection closed" bug be fixed?

[Sin Jeong-hun]

I don't get the message so it's hard to debug that, but some of my
clients report that they get "The underlying connection was closed
unexpectedly" exception. According to this site (http://
http://www.dotnetspider.com/resource...nnection.aspx),
it's a bug of .NET 2.0, and the author suggests that we use
KeepAlive=false until Microsoft fixes it.

It seems like almost 5 years have passes since the release of .NET
2.0, and this stilll exists. Should I wait for the fix, or use
KeepAlive=false instead?

[Peter Duniho]

On Fri, 24 Oct 2008 14:58:45 -0700, Sin Jeong-hun <ty*******@gmail.com>
wrote:

I don't get the message so it's hard to debug that, but some of my
clients report that they get "The underlying connection was closed
unexpectedly" exception. According to this site (http://
http://www.dotnetspider.com/resource...nnection.aspx),
it's a bug of .NET 2.0, and the author suggests that we use
KeepAlive=false until Microsoft fixes it.

It seems like almost 5 years have passes since the release of .NET
2.0, and this stilll exists. Should I wait for the fix, or use
KeepAlive=false instead?

You should either set KeepAlive to false or, much better, simply write
your code to tolerate a closed connection.

My cursory reading of the HTTP specification suggests that there is no
reason for a client to expect an HTTP server to keep the connection open
indefinitely, even when "Connection: Keep-Alive" is sent. Even if the
protocol indicated that it should (and as near as I can tell, it doesn't),
a connection can _always_ wind up closed or reset for some other reason.

In other words, in spite of that author's insistence that this is a bug
that Microsoft needs to fix, I see no evidence of that. It appears to be
a natural consequence of an HTTP server behaving normally.

So, any code should be prepared for an error like that, and deal with it
appropriately. Probably the most sensible thing to do, at least the first
time you get the error for a given request, is to simply make a new
connection and request to the server. That's what a web browser would do,
if it opened a connection to an HTTP server and found the connection
closed when it tried to reuse it later.

Pete

[=?Utf-8?B?VGVzdGVy?=]

Thanks. I created separate WebRequests for each request using
WebRequest.Create(), and common underlying connection seems to be managed by
the .NET framework. I didn't explicitly tell .NET framework to use the same
connection for every requests. And it also looks like there is no way access
the underlying connection (opened by the .NET framework), to check if the
connection is closed or not before sending the request.

Shouldn't the .NET framework check if the connection is closed or not , then
open and use a new connection if it has been closed by web server before
sending a new request ? Checking this for every request and try again seems
to be a lot of typing overhead.

If .NET doesn't do that, is there any way to check if the underlying
connection is closed or not before sending the request?

"Peter Duniho" wrote:

On Fri, 24 Oct 2008 14:58:45 -0700, Sin Jeong-hun <ty*******@gmail.com>
wrote:

I don't get the message so it's hard to debug that, but some of my
clients report that they get "The underlying connection was closed
unexpectedly" exception. According to this site (http://
http://www.dotnetspider.com/resource...nnection.aspx),
it's a bug of .NET 2.0, and the author suggests that we use
KeepAlive=false until Microsoft fixes it.

It seems like almost 5 years have passes since the release of .NET
2.0, and this stilll exists. Should I wait for the fix, or use
KeepAlive=false instead?

You should either set KeepAlive to false or, much better, simply write
your code to tolerate a closed connection.

My cursory reading of the HTTP specification suggests that there is no
reason for a client to expect an HTTP server to keep the connection open
indefinitely, even when "Connection: Keep-Alive" is sent. Even if the
protocol indicated that it should (and as near as I can tell, it doesn't),
a connection can _always_ wind up closed or reset for some other reason.

In other words, in spite of that author's insistence that this is a bug
that Microsoft needs to fix, I see no evidence of that. It appears to be
a natural consequence of an HTTP server behaving normally.

So, any code should be prepared for an error like that, and deal with it
appropriately. Probably the most sensible thing to do, at least the first
time you get the error for a given request, is to simply make a new
connection and request to the server. That's what a web browser would do,
if it opened a connection to an HTTP server and found the connection
closed when it tried to reuse it later.

Pete

[Peter Duniho]

On Fri, 24 Oct 2008 16:13:01 -0700, Tester
<Te****@discussions.microsoft.comwrote:

[...]
Shouldn't the .NET framework check if the connection is closed or not ,
then
open and use a new connection if it has been closed by web server before
sending a new request ? Checking this for every request and try again
seems
to be a lot of typing overhead.

If .NET doesn't do that, is there any way to check if the underlying
connection is closed or not before sending the request?

I'm not sure. I have barely used the WebRequest stuff, so I'm not sure
what level of control you have over the underlying connection.

I suppose if it turns out that as the client code, you have _no_ control
over the connection then my previous reply isn't quite right, as Microsoft
_should_ at least provide that, if not automatically deal with a closed
connection.

Now, all that said, if there's a bug in the framework, it's hard to see
how Microsoft would necessarily be expected to fix it, unless someone
reports it. If someone has reported it, there should be a bug in the
database at http://connect.microsoft.com/ If no one has reported it, then
your first step, assuming you want the bug fixed, would be to report it.

Pete

[Peter Duniho]

On Fri, 24 Oct 2008 16:13:01 -0700, Tester
<Te****@discussions.microsoft.comwrote:

[...]
If .NET doesn't do that, is there any way to check if the underlying
connection is closed or not before sending the request?

For what it's worth, it looks to me as though you might be able to control
the connection state by getting the ServicePoint from the HttpWebRequest,
as well as the ConnectionGroupName, and then pass that name to the
ServicePoint.CloseConnectionGroup() method.

As I mentioned, I don't have a lot of experience in this area, but that
might accomplish what you want. It might even be what Microsoft intends
for you to do when the connection is closed by the server. :)

Yet another possible alternative would be to set the
ServicePoint.MaxIdleTime low enough that the ServicePoint always closes
the connection before the server winds up doing it. How well that would
work probably depends on the actual servers you're dealing with, but I'd
guess a _really_ low MaxIdleTime would probably be less than any server
you might run into.

Pete