Ending the response (Response.Redirect(url)
or Response.Redirect(url, true)
) will not have better performance than Response.Redirect(url, false)
. With false
, since you have control over the code execution, you can simply not execute any more code in the case when you are going to redirect the user.
This is specified in the MSDN entry for Response.Redirect()
:
If you specify true for the endResponse parameter, this method calls the End method for the original request, which throws a ThreadAbortException exception when it completes. This exception has a detrimental effect on Web application performance, which is why passing false for the endResponse parameter is recommended.
You DO need to be concerned about the page lifecycle events, as you noted. You shouldn't continue executing the page events if you are going to Redirect the user (not only for performance). I recently wrote a brief example showing what can happen with poor coding/planning if you don't.
The bottom line of that post is that Response.Redirect()
returns a 302 to the browser. There is a potential for problems when you use Response.Redirect(url, false)
since the page execution continues, and the user can choose to ignore the 302 and instead see the page that would've been rendered... so you need to take steps to ensure they don't see anything you don't want them to see. The NoRedirect add-on for Firefox is helpful when testing this.
For best performance: use "false"
as the endResponse
parameter, ensure you aren't running any further code, and ensure the page isn't going to render any information you don't want a user to see if they ignore the 302.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…