HttpResponse.Close VS KeepAlive

  • Thread starter Thread starter TDC
  • Start date Start date
T

TDC

HttpResponse.Close states it closes the socket to the client...is that
true even if the connection is in "KeepAlive" mode?

Same question for the OutputStream retrieved from the response object?

If KeepAlive is True, is there an required cleanup or dispose methods
that are appropriate at the end of an IHttpHandler.ProcessRequest()
implementation?

Thanks!
 
HttpResponse is not really a connection to the client. its a stream that
talks the i/o threads that have the actual socket connection open (which
is probably to a proxy/firewall not the actual browser).

anyway calling close is all you have to do.

-- bruce (sqlwork.com)
 
Yes, the HttpResponse object is not a NetworkStream, I've got that.
But the documentation says that calling HttpResponse.Close() literally
that it closes the socket to the client.

I'm just trying to make absolutley sure that cleaning up with the
Close isnt defeating a KeppAlive-style web connection.

Tom
 
TDC said:
Yes, the HttpResponse object is not a NetworkStream, I've got that.
But the documentation says that calling HttpResponse.Close() literally
that it closes the socket to the client.
I'm just trying to make absolutley sure that cleaning up with the
Close isnt defeating a KeppAlive-style web connection.
Click to expand...

Did you create the instance of HttpResponse or open the stream? Ans: no. So
don't try to clean it up.
 
I've got one vote yes, call the Close, and another for no, don't call
the Close :)

Using Reflector, it looks like the Close would perform some type of
disconnect from the client, though its hard to tell if thats a
physical (socket) disconnect or more of a logical one.

I'm inclined not to call Close at this point...
 
TDC said:
I've got one vote yes, call the Close, and another for no, don't call
the Close :)

Using Reflector, it looks like the Close would perform some type of
disconnect from the client, though its hard to tell if thats a
physical (socket) disconnect or more of a logical one.

I'm inclined not to call Close at this point...
Click to expand...

You'd be right not to close. In handling a .NET request a context is
created. In this context is a Response object and an open OutputStream.
The context passes through all relevant modules and then handed over to the
appropriate handler (your ASPX page in this case), after that the context
may pass through the modules again.

The underlying .NET framework (or indeed the IIS underneat that) manages the
connection to the client, ordinarily you would not be expected to
unilaterally decide when and if the connection should closed.
 
Thanks for your help!

You'd be right not to close.  In handling a .NET request a context is
created.  In this context is a Response object and an open OutputStream..
The context passes through all relevant modules and then handed over to the
appropriate handler (your ASPX page in this case), after that the context
may pass through the modules again.

The underlying .NET framework (or indeed the IIS underneat that) manages the
connection to the client, ordinarily you would not be expected to
unilaterally decide when and if the connection should closed.
Click to expand...
 
Back
Top