Is Response.End() considered harmful?

Question

TL;DR

Initially I had recommended that you should simply replace all of your calls to [Response.End] with [...] CompleteRequest() calls, but if you want to avoid postback processing and html rendering you'll need to add [...] overrides as well.

Jon Reid, "Final Analysis"

---

Per MSDN, Jon Reid, and Alain Renon:

ASP.NET Performance - Exception Management - Write Code That Avoids Exceptions

The Server.Transfer, Response.Redirect, Response.End methods all raise exceptions. Each of these methods internally call Response.End. The call to Response.End, in turn, causes a ThreadAbortException exception.

ThreadAbortException Solution

HttpApplication.CompleteRequest() sets a variable that causes the thread to skip past most of the events in the HttpApplication event pipeline [--] not the Page event chain but the Application event chain.

...

create a class level variable that flags if the Page should terminate and then check the variable prior to processing your events or rendering your page. [...] I would recommend just overriding the RaisePostBackEvent and Render methods

Response.End and Response.Close are not used in normal request processing when performance is important. Response.End is a convenient, heavy-handed means of terminating request processing with an associated performance penalty. Response.Close is for immediate termination of the HTTP response at the IIS/socket level and causes issues with things like KeepAlive.

The recommended method of ending an ASP.NET request is HttpApplication.CompleteRequest. Keep in mind that ASP.NET rendering will have to be skipped manually since HttpApplication.CompleteRequest skips the rest of the IIS/ASP.NET application pipeline, not the ASP.NET Page pipeline (which is one stage in the app pipeline).

---

Code

Copyright © 2001-2007, C6 Software, Inc as best I could tell.

---

Reference

HttpApplication.CompleteRequest

Causes ASP.NET to bypass all events and filtering in the HTTP pipeline chain of execution and directly execute the EndRequest event.

Response.End

This method is provided only for compatibility with ASP—that is, for compatibility with COM-based Web-programming technology that preceded ASP.NET.preceded ASP.NET. [Emphasis added]

Response.Close

This method terminates the connection to the client in an abrupt manner and is not intended for normal HTTP request processing. [Emphasis added]

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()

If you had employed an exception logger on your app, it will be watered down with the ThreadAbortExceptions from these benign Response.End() calls. I think this is Microsoft's way of saying "Knock it off!".

I would only use Response.End() if there was some exceptional condition and no other action was possible. Maybe then, logging this exception might actually indicate a warning.

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.