Response.End() vs HttpContext.Current.ApplicationInstance.CompleteRequest() [duplicate]

Answer 1

Old Q, and not sure if it helps, but I do essentially the same as your example when creating PDF files to deliver to the browser. However, at the end of processing, I have the following:

    Response.OutputStream.Flush()
    Response.OutputStream.Close()
    Response.End()

The addition of .Close() basically. Seems to work fine in production.

Ed: Just found this too, mentioning Close(): Is Response.End() considered harmful?

Another approach to your problem is simply overriding Page_PreRender() and putting the content delivery code in there (which kind of makes functional sense). Then you definitely won't get any unwanted HTML, and there should be no need for Response.End() at all.

Answer 2

Response.End internally throws the ThreadAbortException to kill the request - if you need to do some kind of cleanup, this needs to be done before the call to Response.End is made.

Response.Redirect and Response.End do not interact well with try / catch blocks. So in your situation, you should do all your logic writing to the response stream in your try / catch, then simply call Response.End after your finally block.