HttpResponse.End vs HttpResponse.Close vs HttpResponse.SuppressContent

I know this is an old question, but I'm including this for the benefit of anyone who might stumble into this post. I've been chasing down a bug that led me to review my use of Response.End, and discovered an MSDN post from a year after this question that could be summarized as "Never, ever use Response.End". Here's what Thomas Marquardt, who designed the Integrated Pipeline for IIS7, says about it:

The End method is also on my “never use” list. The best way to stop the request is to call HttpApplication.CompleteRequest. The End method is only there because we tried to be compatible with classic ASP when 1.0 was released. Classic ASP has a Response.End method that terminates processing of the ASP script. To mimic this behavior, ASP.NET’s End method tries to raise a ThreadAbortException. If this is successful, the calling thread will be aborted (very expensive, not good for performance) and the pipeline will jump ahead to the EndRequest event. The ThreadAbortException, if successful, of course means that the thread unwinds before it can call any more code, so calling End means you won’t be calling any code after that. If the End method is not able to raise a ThreadAbortException, it will instead flush the response bytes to the client, but it does this synchronously which is really bad for performance, and when the user code after End is done executing, the pipeline jumps ahead to the EndRequest notification. Writing bytes to the client is a very expensive operation, especially if the client is halfway around the world and using a 56k modem, so it is best to send the bytes asynchronously, which is what we do when the request ends the normal way. Flushing synchronously is really bad. So to summarize, you shouldn’t use End, but using CompleteRequest is perfectly fine. The documentation for End should state that CompleteRequest is a better way to skip ahead to the EndRequest notification and complete the request.

From http://blogs.msdn.com/b/aspnetue/archive/2010/05/25/response-end-response-close-and-how-customer-feedback-helps-us-improve-msdn-documentation.aspx

I eventually found a simple solution to using Response.End() without getting a ThreadAbortException.

Response.Flush();Response.End();

From my original question, I'd always been trying JUST a Response.End() after sending some content to the response stream.

It seems that if there is unflushed content when you do Response.End(), you get the ThreadAbortException. By doing the Flush immediately before the End, a ThreadAbortException does not actually get thrown.

Seems to be working great - no ThreadAbortException is being thrown now when I use Response.End

update - warning: there is a better method, don't use this, see Ethan's answer instead!

I wouldn't say there is a valid reason to avoid the Response.End. Wanting to avoid the cost of the ThreadAbortException, by letting the page request cycle go on and have it do extra work that isn't necessary doesn't seem right.

ThreadAbortException is a special type of exception meant to stop a thread from execution (its re-thrown automatically even if caught). That said, there are some scenarios where it could do harm (see community content added at the end of ThreadAbortException).

Unless you are in one of those scenarios you should stick to Response.End. Note that some usages around, do a SuppressContent & Response.End, I guess in cases that you want to avoid some stuff that would come from the internal Response.Flush.