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
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.
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).
Causes ASP.NET to bypass all events and filtering in the HTTP pipeline chain of
execution and directly execute the EndRequest event.
This method is provided only for compatibility with ASPthat is, for
compatibility with COM-based Web-programming technology that preceded
ASP.NET.preceded ASP.NET. [Emphasis added]
This method terminates the connection to the client in an abrupt manner and is
not intended for normal HTTP request processing. [Emphasis added]
>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). And how do you accomplish this?
See the link to the code where Jon Reid demonstrated how to set a flag and override the Page's RaisePostBackEvent and Render methods to skip the normal implementation when desired. (You'd probably do this in a base class all your app's pages should inherit from.) web.archive.org/web/20101224113858/http://www.c6software.com/
Just to restate: HttpApplication.CompleteRequest does not terminate the response as Response.End does.
HttpApplication.CompleteRequest also doesn't stop code flow, so subsequent lines keep running. That may not affect what the browser sees, but if those lines do any other processing, it can be really confusing.
I cannot think but that Web Forms is broken by design. What is more performance degrading, calling Response.End() or letting the page load everything and then suppress the response? I cannot see where Response.End() is "more" harmful here. Moreover, Microsoft treats `ThreadAbortedException' as a normal event as evident from this code: referencesource.microsoft.com/#System.Web/UI/Page.cs,4875 One thing that is against Response.End() is that it might fail aborting the response, which might result occasionally in the response being displayed.