When an ASP.NET System.Web.HttpResponse.End() is called, the current thread is aborted?

Question

when a System.Web.HttpResponse.End() is called a System.Thread.Abort is being fired, which i'm guessing is (or fires) an exception? I've got some logging and this is being listed in the log file...

A first chance

exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
12/14/2008 01:09:31::
Error in Path :/authenticate
Raw Url :/authenticate
Message :Thread was being aborted.
Source :mscorlib
Stack Trace :   at System.Threading.Thread.AbortInternal()
   at System.Threading.Thread.Abort(Object stateInfo)
   at System.Web.HttpResponse.End()
   at DotNetOpenId.Response.Send()
   at DotNetOpenId.RelyingParty.AuthenticationRequest.RedirectToProvider()
   at MyProject.Services.Authentication.OpenIdAuthenticationService.GetOpenIdPersonaDetails(Uri serviceUri) in C:\Users\Pure Krome\Documents\Visual Studio 2008\Projects\MyProject\Projects\Services\Authentication\OpenIdAuthenticationService.cs:line 108
   at MyProject.Mvc.Controllers.AuthenticationController.Authenticate() in C:\Users\Pure Krome\Documents\Visual Studio 2008\Projects\MyProject\Projects\MVC Application\Controllers\AuthenticationController.cs:line 69
TargetSite :Void AbortInternal()
A first chance exception of type 'System.Threading.ThreadAbortException' occurred in Ackbar.Mvc.DLL
An exception of type 'System.Threading.ThreadAbortException' occurred in Ackbar.Mvc.DLL but was not handled in user code

Is this normal behavior and is it possible to gracefully abort instead of (what looks like) a sudden abrupt abort?

Update

So far it the common census that it's by design. So i'm wondering if it's possible we could take this question and see if we could tweak the code to make it not feel like we're ending the thread prematurely and gracefully exit ... Possible? Code examples?

Feverfew

Hi, In addition to the answers below you might want to check the following: support.microsoft.com/kb/312629/EN-US – Sailcloth

See related response-end-considered-harmful – Java

Answer 1

Yes, this is indeed by design. Microsoft has even documented it. How else would you stop the rest of your program from execution?

Weatherley

See answers on response-end-considered-harmful question – Java

Answer 2

There is no such thing as a "graceful" abort. You could simply Flush() the response, though, instead of ending it and let the framework take care of closing the connection for you. I'm assuming in this case that you want the response sent to the client, i.e., the typical case.

According to MSDN, calling Response.End() throws the ThreadAbortException when the response ends prematurely. You really should only call Response.End() when you want the exception raised.

Zamindar

I've always wondered what the exact definition of "prematurely" is in this context... Is that documented anywhere? I've always taken it to mean "if there's code to be executed after Response.End() is called". – Percipient

Answer 3

There's nothing inherently ungraceful about an exception recursing up your stack to stop the current execution. Certainly no more than you throwing an exception and catching it at some lower place in your exception.

I'd look at filtering it from your logging. If you're using the ASP.Net health monitoring you can configure/map each exception to a given provider (event log, mail, etc) to control whether you get a notification for threadabort exceptions or not. If it's custom logging then I'd just add an if to check for it.

Note that you can't eat a ThreadAbortException so even if your logging code is doing something like catch(Exception e) { // log exception and then do not throw again } the ThreadAbortException will still be raised again by the framework once your catch block exits.

Empale

I've always try and avoid exceptions UNLESS there is something unexpected. From my persepective, if we want to REDIRECT, that's expected .. so so such, we know what we're trying to do (stop current stuff, goto new URI) .. so i don't see why they made it not gracefully end. – Feverfew

So I think I would tend to agree with you that you shouldn't design libraries this way. none the less I can't really think of any way that this could possibly be implemented in the .Net framework without an exception. In this case, expected or not, an exception is called for. – Empale

Answer 4

Don't use Response.End() method because it uses Application.End() and stop the application. Further use HTTP request or response violating Page Life Cycle. Use HttpContext.Current.Response.Close() or HttpContext.Current.ApplicationInstance.CompleteRequest();

Cohesion

please add the source.that will help more clear if someone refers – Ornithopter

HttpContext.Current.Response.Clear(); HttpContext.Current.Response.ClearHeaders(); HttpContext.Current.Response.Buffer = true; HttpContext.Current.Response.ContentType = "application/ms-excel"; HttpContext.Current.Response.AddHeader("Content-Disposition", "attachment;filename=" + FileToDownLoad.Name); HttpContext.Current.Response.Charset = "utf-8"; HttpContext.Current.Response.WriteFile(FileToDownLoad.FullName); HttpContext.Current.Response.Flush(); HttpContext.Current.Response.Close(); HttpContext.Current.ApplicationInstance.CompleteRequest(); – Cohesion

Answer 5

I used all above changes but still I was getting same issue on my web application.

Then I contacted my hosting provide & asked them to check if any software or antivirus blocking our files to transfer via HTTP. or ISP/network is not allowing file to transfer.

They checked server settings & bypass the "Data Center Shared Firewall" for my server & now our application started to download the file.

Hope this answer will help someone.This is what worked for me

Systematology