Most of us don't think too much about bandwidth usage of our applications since the first rule of optimization is: don't. If we want to speed things up we might just gzip the pages or whatever but while I am working on a system which is massively multi-user, any savings I can make in the response are potentially large savings in bandwidth, something which is great for cloud services which charge for bandwidth.
I realised much to my surprise that if you call Response.Redirect in the code behind after a postback, all this does is add in some html to the response like this:

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="/blah/blah.aspx">here</a>.</h2>
</body></html>


...but the body of the page is still returned after this html code even though the browser will shortly be redirecting. This effectively doubles the bandwidth requirement for the system since every page is returned once on the GET and once on the POST. I decided to write a method that all pages could call for redirect purposes which would only return the redirect code and nothing else. I had to play around with all the similar and confusing methods that are available in ASP.net and ended up with this:


 internal static void Redirect(HttpContext context, string location)
{
context.Response.Clear();
context.Response.Redirect(location, false);
context.ApplicationInstance.CompleteRequest();
context.Response.End();
}

The first line clears anything that is already in the response. The second effectively generates the html that will cause the redirect and "false" means it won't throw a thread abort exception in the process. The third line ensures that no other filters or pipelines will be called (which might add additional data to the response) and the last one ensures that the default Render method is not called which would put the page into the output.