Redirecting Application-Level Error Handler

protected void Application_BeginRequest(object sender, EventArgs e)
    {


        const int maxFileSizeKBytes = 10240; //10 MB
        const int maxRequestSizeKBytes = 305200; //~298 MB

        if (Request.ContentLength > (maxRequestSizeKBytes * 1024))
        {
            Response.Redirect(".aspx?requestSize=" + Request.ContentLength.ToString());
        }


        for (int i = 0; i < Request.Files.Count; i++)
        {
            if (Request.Files[i].ContentLength > (maxFileSi开发者_StackOverflowzeKBytes * 1024))
            {
                Response.Redirect(".aspx?fileSize=" + Request.Files[i].ContentLength.ToString());
            }
        }

    }

This code is in Global.asax.cs page. I need to redirect to the page that triggered this check. And I need to know the ticketId or projectId parameter. For example I create new ticket at the View Project page /Project/ViewProject.aspx?projectId=1 I need to redirect to this page with a meaningful message to the user, because I think that redirecting to another page to display the error message is not a good idea.

---

Why don't you put these checks in the Load handler of a base Page class that ViewProject (and anything else needing the checks) derives from? Then you can just make an error Label visible if the check fails. Untested code:

public class BasePage : Page{
  protected virtual Label ErrorLabel { get; set; };
  protected override OnLoad(object sender, EventArgs e) {
    base.OnLoad(sender, e);

    const int maxFileSizeKBytes = 10240; //10 MB
    const int maxRequestSizeKBytes = 305200; //~298 MB

    if (Request.ContentLength > (maxRequestSizeKBytes * 1024))
    {
        ErrorLabel.Text = "Request length "+Request.ContentLength+" was too long."
        ErrorLabel.Visible = true;
    }


    for (int i = 0; i < Request.Files.Count; i++)
    {
        if (Request.Files[i].ContentLength > (maxFileSizeKBytes * 1024))
        {
            ErrorLabel.Text = "File length "+ Request.Files[i].ContentLength +" was too long."
            ErrorLabel.Visible = true;
        }
    }
  }
}

public class ViewProject : BasePage {
  protected override Label ErrorLabel {
    get { return LocalErrorLabel; } // something defined in HTML template
    set { throw new NotSupportedException(); }
  }
}

This way you stay on the same page and you already have ticketId and projectId.

---

To handle application errors in the global.asax file, you should consider using the handler designed for this purpose:

protected void Application_Error(object sender, EventArgs e)
{
    //get exception causing event
    Exception lastException = Server.GetLastError().GetBaseException();

    //log exception, redirect based on exception that occurred, etc.
}

your 'settings' such as maxRequestSizeKBytes should be defined in the web.config using the MaxRequestLength property

Example:

<system.web>
    <httpRuntime maxRequestLength="305200" executionTimeout="120" />
</system.web>

---

you can try something like this with Server.Transfer. The URL will remain the same. Doing a Response.Redirect would send a 302 to the same page again (which might sometimes send you in an infinite loop . ex. try having Response.Redirect(mypage.aspx) in page load of mypage.aspx).

 string errorPage = "~//Error.aspx";
 Server.Transfer(errorPage, false);    
 HttpContext.Current.Server.ClearError();
 HttpContext.Current.Response.ClearContent();

In either case you should have the second parameter to false to avoid thread abort exception. ex.

Response.Redirect("mypage.aspx",false); 
Server.Transfer("myerror.aspx",false);

---

These limits are actually constrained in the web.config as a best practice in order to prevent people doing a DoS on your site. You may be best served to provide a visual cue to the user about file size constraints and then let the standard error handler take over.

http://msdn.microsoft.com/en-us/library/e1f13641.aspx

It's not a good idea to give error details to users; you should instead reserve that for Admins. File size errors are just that ... errors, and not related to validation which is what you should be providing feedback to users on.