Response.Redirect() ThreadAbortException Bubbling Too High Intermittently - asp.net

I understand (now) that Response.Redirect() and Response.End() throw a ThreadAbortException as an expensive way of killing the current processing thread to emulate the behaviour of ASP Classic's Response.End() and Response.Redirect methods.
However.
It seems intermittently in our application that the exception bubbles too high. For example, we have a page that is called from client side javascript to return a small string to display in a page.
protected void Page_Load(object sender, EventArgs e)
{
// Work out some stuff.
Response.Write(stuff);
Response.End();
}
This generally works, but sometimes, we get the exception bubbling up to the UI layer and get part of the exception text displayed in the page.
Similarly, else where we have:
// check the login is still valid:
if(!loggedin) {
Response.Redirect("login.aspx");
}
In some cases, the user is redirected to login.aspx, in others, the user gets an ASP.NET error page and stack dump (because of how our dev servers are configured).
i.e. in some cases, response.redirect throws an exception all the way up INSTEAD of doing a redirect. Why? How do we stop this?

Have you tried overloading the default Redirect method and not ending the response?
if(!loggedin) {
Response.Redirect("login.aspx", false);
}

You can use the following best-practice code instead, as explained by this answer to prevent the exception from happening in the first place:
Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();

Since I was looking for an answer to this question too, I am posting what seams to me a complete solution, rounding up the two above answers:
public static void Redirect(this TemplateControl control, bool ignoreIfInvisible = true)
{
Page page = control.Page;
if (!ignoreIfInvisible || page.Visible)
{
// Sets the page for redirect, but does not abort.
page.Response.Redirect(url, false);
// Causes ASP.NET to bypass all events and filtering in the HTTP pipeline
// chain of execution and directly execute the EndRequest event.
HttpContext.Current.ApplicationInstance.CompleteRequest();
// By setting this to false, we flag that a redirect is set,
// and to not render the page contents.
page.Visible = false;
}
}
Source:
http://www.codeproject.com/Tips/561490/ASP-NET-Response-Redirect-without-ThreadAbortExcep

Related

Page.AsyncTimeout - endless timeout?

I saw an example of forever iframe implementation ( comet simulation ) , so I decided to test it but with the addition of asynchronous approach , so that there will be no blocking.
Pretty simple :
I have a page (index.html) with hidden iframe which has SRC of AdminPush.aspx:
/*1*/ protected void Page_Load(object sender, EventArgs e)
/*2*/ {
/*3*/ UpdateMessage();
/*4*/ }
/*5*/
/*6*/
/*7*/ protected void UpdateMessage()
/*8*/ {
/*9*/ HttpContext.Current.Response.ContentType = "text/html";
/*10*/ Response.Write("<script >parent.UpdateMessage(DateTime.Now.Second)</script>");
/*11*/ Response.Flush();
/*12*/
/*13*/ //async part goes here !!
/*14*/ this.RegisterAsyncTask(new PageAsyncTask(async cancellationToken =>
/*15*/ {
/*16*/ await Task.Delay(2000, cancellationToken);
/*17*/ UpdateMessage();
/*18*/ }));
/*19*/ }
On the AdminPush.aspx Page I added :
Async="true"
On the html page (index.html) I added :
function UpdateMessage(Message)
{
console.log(Message);
}
function setupAjax() //body Onload - calls it.
{
var iframe = document.createElement("iframe");
iframe.src = "adminpush.aspx";
iframe.style.display = "none";
document.body.appendChild(iframe);
}
So basically the iframe is being injected with script comands , which updates the parent of the iframe which is index.html.
It is working.
But when I tested it - it stopped updating after 45 seconds.
I thought it had to do with requestTimeout prop in web.config - but it wasnt.
It was related to the missing AsyncTimeOut prop in the AdminPush.aspx page.
Question #1:
According to msdn AsyncTimeout :
Gets or sets a value indicating the time-out interval used when
processing asynchronous tasks.
But it also says :
A TimeSpan that contains the allowed time interval for completion of
the asynchronous task. The default time interval is 45 seconds.
please notice that I "delay" 2 sec every time
at first I set the timeout to 1 minute , but then it failed also. I thought that the timeout should be regarding each operation , and not to sum(all async operations)
Why is it like that ? it suppose to be timeout for async task ! (single) but it behaves as sum(tasks)
The wording here are misleading. any clarification ?
Question #2:
I need to set it to max value. what is that value ? but still , I need it so support a browser for a very long time. so I'm afraid that this value won't help either.
Is there any way I can RESET this value (after n cycles) ?
I know that there are other solutions/libraries like signalR which are doing the job, still, it does not prevent learning how other stuff are done.
The idea of Asynchronous Pages is to free IIS so more users can be served, if you create a page that "never" finishes, you will eat up all your resources.
That been said... if you still want to do it...
We "know" (documentation), Asynchronous Pages work by splitting the execution of the page in 2... everything BEFORE the Background Tasks and everything AFTER the tasks, in that way IIS can process more requests while the background tasks finish their work. (there is more to it, but that is enough for now)
So... they "must" be creating some kind of Task Manager (like a root/main task) that executes all the registered tasks in sequence, in that way IIS starts processing the page, fires up the task manager, frees IIS, the task manager keeps processing the tasks and when it finishes, it returns control to IIS.
That would explain why the AsyncTimeout controls all the registered tasks instead of one-by-one (The timeout is actually applied to the Task Manager).
I tested a variation of your code with a timeout of 6000 seconds and it works:
C#:
protected void Page_Load(object sender, EventArgs e)
{
Page.RegisterAsyncTask(new PageAsyncTask(ProcessTask));
}
protected async Task ProcessTask()
{
await Task.Delay(1000);
Response.Write(DateTime.Now.ToLongTimeString() + "<br/>");
Response.Flush();
Page.RegisterAsyncTask(new PageAsyncTask(ProcessTask));
}
aspx:
<%# Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Sample03.Default" Async="true" AsyncTimeout="6000" %>
Hope it helps.

ASP.Net PreSendRequestHeaders unable to access session

The goal is to intercept when user code calls Response.Redirect and alter the URL the browser is being redirected to. To alter this URL, I need access to Session (stored in Session is information that tells me what I should put in this URL.) Mostly I'm just appending a query argument to the redirect location under a circumstance.
PreSendRequestHeaders does let me alter Response.RedirectLocation. That's fine. However, I'm unable to access Session state from here. It's apparently been released before this event is fired.
So, I need a way to get this information into PreSendRequestHeaders; or I need another way to accomplish this. Ultimately my goal is to just append an argument to the query string of wherever the browser is being redirected.
If you can modify the code that writes to Session then you can use Context.Items.
For example, before the Response.RedirectPermanent method existed, I used the following:
//in some library
public static void PermanentRedirect(this HttpContext context, string url)
{
context.Items["IsPermanentRedirect"] = true;
context.Response.Redirect(url);
}
//in global.asax
void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
if (Response.IsRequestBeingRedirected && (bool) (Context.Items["IsPermanentRedirect"] ?? false))
{
Response.Status = "301 Moved Permanently";
}
}

Application_Error takes precedence over Page_Error

I have both Page_Error method in page that raises error, and Application_Error in global.asax. When Page throws exception, executed routine is Application_Error. But for that one particular page I would like to have different handling in Page_Error. Is there any way to achieve it?
Thanks,
Pawel
P.S. Perhaps it is because exception being thrown is caused by too large file being uploaded (I tested file upload page how it handles files bigger then web.config setting) and Page_Error is not yet wired?
From the same the function of Page_Error you can check for the page and if is the one you look you have diferent behavior.
if( HttpContext.Current.Request.Path.EndsWith("YourFileName.axd", StringComparison.InvariantCultureIgnoreCase))
{
// the diferent way
}
else
{
}
The next way is from inside the page with the diferent behavior.
public override void ProcessRequest(HttpContext context)
{
try
{
base.ProcessRequest(context);
}
catch (Exception x)
{
// here is the different, since you catch here is not move to the Page_Error
// except is a code error... in any case you can do an extra error clear.
}
}

How do I crash the App Pool?

Our ASP.NET 2 web application handles exceptions very elegantly. We catch exceptions in Global ASAX in Application_Error. From there we log the exception and we show a friendly message to the user.
However, this morning we deployed the latest version of our site. It ran ok for half an hour, but then the App Pool crashed. The site did not come back up until we restored the previous release.
How can I make the app pool crash and skip the normal exception handler? I'm trying to replicate this problem, but with no luck so far.
Update: we found the solution. One of our pages was screenscraping another page. But the URL was configured incorrectly and the page ended up screenscraping itself infinitely, thus causing a stack overflow exception.
The most common error that I have see and "pool crash" is the loop call.
public string sMyText
{
get {return sMyText;}
set {sMyText = value;}
}
Just call the sMyText...
In order to do this, all you need to do is throw any exception (without handling it of course) from outside the context of a request.
For instance, some exception raised on another thread should do it:
protected void Page_Load(object sender, EventArgs e)
{
// Create a thread to throw an exception
var thread = new Thread(() => { throw new ArgumentException(); });
// Start the thread to throw the exception
thread.Start();
// Wait a short while to give the thread time to start and throw
Thread.Sleep(50);
}
More information can be found here in the MS Knowledge Base
Aristos' answer is good. I've also seen it done with a stupid override in the Page life cycle too when someone change the overriden method from OnInit to OnLoad without changing the base call so it recursed round in cirlces through the life cycle: i.e.
protected override void OnLoad(EventArgs e)
{
//some other most likely rubbish code
base.OnInit(e);
}
You could try throwing a ThreadAbortException.

IHttpModule.BeginRequest firing 2X, Application_BeginRequest firing 1X

I'm running VS 2008 and .NET 3.5 SP1.
I want to implement hit tracking in an HttpModule in my ASP.NET app. Pretty simple, I thought. However, the BeginRequest event of my HttpModule is firing twice for each page hit. The site is very simple right now...no security, just a bit of database work. Should log one row per page hit. Why is this event firing twice?
Moreover, IHttpModule.BeginRequest actually fires a different number of times for the first page hit when running for the first time (from a closed web browser)...3 times when I'm hitting the DB to provide dynamic data for the page, and only 1 time for pages where the DB isn't hit. It fires 2 times for every page hit after the first one, regardless of whether or not I'm touching the DB.
It's interesting to note that Application_BeginRequest (in Global.asax) is always firing only once.
Here's the code:
using System;
using System.Data;
using System.Data.Common;
using System.Net;
using System.Web;
using BluHeron.BusinessLayer;
using Microsoft.Practices.EnterpriseLibrary.Data.Sql;
namespace BluHeron.HttpModules
{
public class SiteUsageModule : IHttpModule
{
public void Init(HttpApplication httpApp)
{
httpApp.BeginRequest += OnBeginRequest;
}
static void OnBeginRequest(object sender, EventArgs a)
{
UsageLogger.LogSiteUsage(((HttpApplication)sender).Context.Request);
}
public void Dispose()
{ }
}
public static class UsageLogger
{
public static void LogSiteUsage(HttpRequest r)
{
string ipAddress = GetHostAddress(Dns.GetHostAddresses(Dns.GetHostName()));
string browserVersion = r.Browser.Type;
string[] urlChunks = r.RawUrl.Split('/');
string page = urlChunks[urlChunks.GetLength(0)-1];
SqlDatabase db = new SqlDatabase(Common.GetConnectionString());
DbCommand cmd = db.GetStoredProcCommand("LogUsage");
db.AddInParameter(cmd, "IPAddress", SqlDbType.NVarChar, ipAddress);
db.AddInParameter(cmd, "BrowserVersion", SqlDbType.NVarChar, browserVersion);
db.AddInParameter(cmd, "PageName", SqlDbType.NVarChar, page);
db.AddInParameter(cmd, "Notes", SqlDbType.NVarChar, "");
db.ExecuteNonQuery(cmd);
}
private static string GetHostAddress(IPAddress[] addresses)
{
foreach (IPAddress ip in addresses)
{
if (ip.ToString().Length <= 15)
{
return ip.ToString();
}
}
return "";
}
}
}
This might be too late for the answer but can be useful for someone else. I faced with the same problem. BeginRequest event triggered for twice for each request. I debugged the code and realized that the first trigger for actual resource request but the second is result of "favicon.ico" request. At the beginning of BeginRequest event, a simple check for favicon.ico request eliminates second execution of the method.
public void Application_BeginRequest(object sender, EventArgs e) {
HttpApplication app = (HttpApplication)sender;
HttpContext ctx = app.Context;
if (ctx.Request.Path == "/favicon.ico") { return; }
quite late on this, but ran into the same issue. In our case it was due to the anonymous request first that returns the 401 per the RFC. The second request authenticates.
The "Default Document" part of IIS seems to fire a second BeginRequest event.
If you have determined that the Request.Path is the same for the HttpApplication in both event handlers and your URL ends with a slash, try adding a URL Rewrite rule to shortcut the "Default Document" processing.
This is interesting. I removed the reference to the CSS file from the master page and I'm getting fewer repeat hits in the HttpModule for certain browsers (as was suggested), but I'm still getting repeats. I have 6 browsers installed, and I'm getting some variation between them.
For reference, this is the URL I'm plugging in to my browsers for this test:
http://localhost/BluHeron
default.aspx is set as the start page and is indeed returned for the aforementioned URL. I'm using HttpRequest.RawUrl for reporting which page the user hit. Specifically, I'm splitting the RawUrl string and just reporting the last item in the array of strings (see code).
Every single browser is reporting hitting default.aspx, as expected (RawUrl = /BluHeron/default.aspx).
4 of the 6 browsers are also reporting BluHeron (RawUrl = /BluHeron).
3 of the 6 browsers are also recording a blank in the database (RawUrl = /BluHeron/).
There are a couple ways I can get accurate reporting of how many people are hitting which pages.
Select from the database only rows that actually list one of my pages (ignore /BluHeron and blanks)
Just use Application_BeginRequest in the global.asax file, which seems to consistently get called only once per page hit.
Get this figured out.
So, I've got options for getting good reports even with crappy data in the database. I would prefer to understand what's going on here and not to have junk in the database.
Thanks for looking, everyone!
We solved this by using
HttpContext.Current.ApplicationInstance.CompleteRequest();
This should prevent the the twice fire you are seeing.
One possibility is that there are other requests going on that you might not be considering. For example, let's say your ASPX page references some images or CSS files. If those requests go through the ASP.NET pipeline then your module will be called and they'll register as hits.
Also, when you say IHttpModule.BeginRequest, do you mean that in IHttpModule.Init() you are hooking up HttpApplication.BeginRequest? If so then the reason I mention above might still apply.
Disable Browser Link in Visual Studio 2013 and up, which causes the second request.
This occurs when an Application is run from Visual Studio.

Resources