Response.End () vs HttpContext.Current.ApplicationInstance.CompleteRequest ()

Question

Users of our application download the application at least once every two seconds during the day.

Previous scenario:

We used Response.End () to disconnect from the client after the user loads the attachment. Since we had performance issues, we started logging exceptions, and one of the most recurring was the interruption exception. Since we get attachment to the web service, we need to do some cleanup, and we cleared the try-catch-finally block. After some research, I realized that any code after Response.End () will not be executed, even if it is at the end of the block. Is it correct?

Current scenario:

I read the thread in the stack overflow about Response.End (), which is harmful, and should be used only when it is really necessary, so I decided to use HttpContext ... CompleteRequest (). This code performs the cleanup, but the html that is displayed is added to the downloaded application. I tried to override the Render and RaisePostBackEvent suggested in the same article, but the problem still persists. Any idea on how to solve this problem would be helpful.

The code:

HttpContext.Current.Response.Clear(); Response.ClearContent(); Response.ClearHeaders(); Response.AddHeader("Content-Disposition", "attachment; filename=" + filename); Response.AddHeader("Content-Length", fileContent.Length.ToString()); Response.ContentType = "application/octet-stream"; Response.BinaryWrite(fileContent); Response.Flush(); 

Answer 1

Response.End internally throws a ThreadAbortException to kill the request - if you need to do some cleanup, you need to do this before the Response.End call is made.

Response.Redirect and Response.End interact poorly with try / catch blocks. So in your situation, you have to do all your logical writing to the response stream in try / catch, and then just call Response.End after your final block.

Answer 2

Old Q, and not sure if this helps, but I am doing essentially the same thing as your example when creating PDF files for delivery to the browser. However, at the end of the processing, I have the following:

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

Adding .Close () basically. It seems to work great in production.

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

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