Is Response.End() considered harmful?

Question

This KB Article says that ASP.NET\'s Response.End() aborts a thread.

Reflector shows that it looks like this:

public void End()
{
            


        

Answer 1

I disagree with the statement "Response.End is harmful". It's definitely not harmful. Response.End does what it says; it ends execution of the page. Using reflector to see how it was implemented should only be viewed as instructive.

---

My 2cent Recommendation
AVOID using Response.End() as control flow.
DO use Response.End() if you need to stop request execution and be aware that (typically)* no code will execute past that point.

---

* Response.End() and ThreadAbortExceptions.

Response.End() throws a ThreadAbortException as part of it's current implementation (as noted by OP).

ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block.

To see how to write code that must deal with ThreadAbortExceptions, see @Mehrdad's reply to SO How can I detect a threadabortexception in a finally block where he references RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup Method and Constrained Execution Regions

---

The Rick Strahl article mentioned is instructive, and make sure to read the comments as well. Note that Strahl's issue was specific. He wanted to get the data to the client (an image) and then process hit-tracking database update that didn't slow down the serving of the image, which made his the problem of doing something after Response.End had been called.

Answer 2

This question appears near the top of all google searches for information on response.end so for other searches like myself who wish to post CSV/XML/PDF etc in response to an event without rendering the entire ASPX page, this is how I do it. (overriding the render methods is overly complex for such a simple task IMO)

// Add headers for a csv file or whatever
Response.ContentType = "text/csv"
Response.AddHeader("Content-Disposition", "attachment;filename=report.csv")
Response.AddHeader("Pragma", "no-cache")
Response.AddHeader("Cache-Control", "no-cache")

// Write the data as binary from a unicode string
Dim buffer As Byte()
buffer = System.Text.Encoding.Unicode.GetBytes(csv)
Response.BinaryWrite(buffer)

// Sends the response buffer
Response.Flush()

// Prevents any other content from being sent to the browser
Response.SuppressContent = True

// Directs the thread to finish, bypassing additional processing
HttpContext.Current.ApplicationInstance.CompleteRequest()

Answer 3

I've used Response.End() in both .NET and Classic ASP for forcefully ending things before. For instance, I use it when there is a certian amount of login attempts. Or when a secure page is being accesed from an unauthenticated login (rough example):

    if (userName == "")
    {
        Response.Redirect("......");
        Response.End();
    }
    else
    {
      .....

When serving files to a user I'd use a Flush, the End can cause issues.

Answer 4

I've only used Response.End() as a testing/debugging mechanism

<snip>
Response.Write("myVariable: " + myVariable.ToString());
Response.End();
<snip>

Judging from what you have posted in terms of research, I would say it would be a bad design if it required Response.End

Answer 5

On classic asp, I had a TTFB (Time To First Byte) of at 3 to 10 seconds on some ajax calls, much larger than the TTFB on regular pages with many more SQL calls.

The ajax returned was a segment of HTML to be injected into the page.

The TTFB was several seconds longer than the render time.

If I added a response.end after the render, the TTFB was greatly reduced.

I could get the same effect by emitting a "</body></html>", but this probably doesn't work when outputting json or xml; here response.end is needed.

Answer 6

On the question of "I still don't know the difference between Response.Close and CompleteRequest()" I would say:

Do prefer CompleteRequest(), don't use Response.Close().

See the following article for a well-done summary of this case.

Be aware that even after calling CompleteRequest() some text (e.g. redndered from ASPX code) would be appended to the response output stream. You can prevent it by overriding Render and RaisePostBackEvent methods as described in the following article.

BTW: I agree with preventing of using Response.End(), especially when writing data to the http stream to emulate file download. We've used the Response.End() in the past until our log file became full of ThreadAbortExceptions.