Re: How to intercept error when httpRuntime maxRequestLength is ex

From: Hermit Dave (hermitd.REMOVE_at_CAPS.AND.DOTS.hotmail.com)
Date: 08/30/04 

Date: Mon, 30 Aug 2004 10:00:26 +0100

was it of any help ? 

-- 
Regards,
Hermit Dave
(http://hdave.blogspot.com)
"Hermit Dave" <hermitd.REMOVE@CAPS.AND.DOTS.hotmail.com> wrote in message
news:OrK7a4ejEHA.1464@TK2MSFTNGP10.phx.gbl...
> okay apologies on my part... i have this problem of not reading the
complete
> information
>
> i never read about HttpPostedFile.. so didnt know that it was the
exception
> that was being thrown due to content length being exceeded.
> Again - sorry for not reading it fully.
>
> i am copying this contents of a discussion we had on MSWebDev.. it has
some
> client side javascript and http module which could be helpful.. and it
will
> also help you understand why you are getting the error and you cant handle
> it..
>
> ---------------------------
>
> <html>
> <head>
>  <script type="text/javascript">
>   function CheckAttachment()
>   {
>    var fso = new
> ActiveXObject("Scripting.FileSystemObject");;
>    if (fso.GetFile(document.all.FileUpload.value).size
> > 4000000)
>    {
>     document.all.ErrorMsg.innerHTML = "File to large!";
>     return false;
>    }
>    return true;
>   }
>  </script>
> </head>
> <body>
>  <form enctype="multipart/form-data" method="post" onsubmit="return
> CheckAttachment()">
>   File: <input type="file" id="FileUpload" name="FileUpload"
> /><br />
>   <input type="Submit" value="Upload" /><br />
>   <span id="ErrorMsg" name="ErrorMsg"></span>
>  </form>
> </body>
> </html>
>
> --------------------------------------------------------------------------
--
> ------
>
> the following code in an HttpModule can read the entire stream and then
> redirect to an error page. Using buffering means that the entire file
won't
> be sucked into memory in a single shot. However if all you want to do is
> reject the file for being too large the connection may be tied up for some
> considerable time before the user gets the error message. This ties in
with
> Jos's comments of using a secondary progress window on the client to
> potentially recover the broken request scenario:
>
> Apologies for the formatting...
>
> public void BeginRequest(Object source, EventArgs e) {
>  HttpRequest request = HttpContext.Current.Request;
>    if (request.ContentLength > 4096000)
>    {
>       HttpApplication app = source as HttpApplication;
>       HtttpContext context = app.Context;
>       HttpWorkerRequest wr =
>    (HttpWorkerRequest)(context.GetType().GetProperty
>     ("WorkerRequest", BindingFlags.Instance |
> BindingFlags.NonPublic).GetValue(context, null));
>       byte[] buffer;
>       if (wr.HasEntityBody())
>       {
>         int contentlen = Convert.ToInt32(wr.GetKnownRequestHeader(
>
> HttpWorkerRequest.HeaderContentLength));
>    buffer = wr.GetPreloadedEntityBody();
>    int received = buffer.Length;
>    int totalrecv = received;
>    if (!wr.IsEntireEntityBodyIsPreloaded())
>    {
>     buffer = new byte[65535];
>     while (contentlen - totalrecv >= received)
>     {
>      received =
>      wr.ReadEntityBody(buffer,
> buffer.Length);
>      totalrecv += received;
>     }
>     received =
>     wr.ReadEntityBody(buffer, contentlen - totalrecv);
>    }
>   }
>   context.Response.Redirect("~/Error.aspx");
>  }
> }
>
> --------------------------------------------------------------------------
--
>
> To redirect the client your server has to send back a response. The
> redirection is contained in the HTTP headers.
>
> To accept a response the client first has to finish requesting the current
> page.
>
> You're rejecting the request itself.
>
> The client isn't going to be expecting a response given that it's not even
> finished telling the server what it wants.
>
>
> --------------------------------------------------------------------------
--
> --
>
> I can understand why the browser displays the message it does on the
client
> side.
>
> What I can't understand is why I can't trap the request, check the content
> length and reject it myself on the server side. By reject I mean
redirecting
> the user to my own custom error screen if they're attempting to post data
> that's deemed too large. After installing an HttpModule and adding my own
> BeginRequest handler, checking the content length and attempting a
redirect
> I would have thought this would prevent the file being uploaded and the
> transfer taking place. I thought the BeginRequest was the first call
within
> the ASP.NET pipeline allowing me to url map, redirect the user, modify the
> request etc.
>
>
> -- 
>
> Regards,
>
> Hermit Dave
> (http://hdave.blogspot.com)
> "Jesse" <Jesse@discussions.microsoft.com> wrote in message
> news:B8879A40-C914-4C9A-B9EF-8AEDA1A9E86A@microsoft.com...
> > I'm going to have to disagree with you.  I have full error handling set
up
> on
> > my site.  Error logging in global.asax and custom error setup in
> web.config.
> >
> > I even tried to explicity catch the System.Web.HttpException that is
> thrown
> > by exceeding the maxRequestLength and then redirecting to a friendly
page.
> > Still no luck there.  The only thing that the redirection causes to
happen
> is
> > that the application_error event now gets fired 3 times.  I'll get three
> > errors logged and still end up on the dns error page.
> >
> > Go ahead and test this out by stepping through it with the debugger.
I'm
> > getting tired of people saying to catch this problem by checking
> > httpPostedFile.ContentLength.  You can't do it.  The code will never be
> hit
> > on your page because the runtime throws the exception.  So therefore you
> > would think that you could catch it in global.asax, and you can, but any
> > redirection will not work.  Why? That is the question.
> >
> > Don't tell me the that the client can't contact the server in these
> > instances. I'm stepping through it with the debugger man.  Why don't you
> > setup a test and then you will see.  You'll get hte dns error after the
> > server has been hit.  I don't know what you mean by "the client browser
> could
> > not contact the server".  It's obviously hitting the server.
> >
> > Has microsoft actually setup an examlpe of this?  I can send a simple
> > example solution to anybody that needs proof.
> >
> >
> >
> > "Hermit Dave" wrote:
> >
> > > its a 2 part thing. if the client browser could not contact the server
> in
> > > the first place then it will throw its on error in the form of server
> not
> > > found / dsn error
> > >
> > > however as Paul mentioned if the error occurred in your code.. then
you
> > > could handle it. sometimes the server is busy serving and doesnt
> respond...
> > > at that point if you have your custom errors page then it will
redirect
> it
> > >
> > > -- 
> > >
> > > Regards,
> > >
> > > Hermit Dave
> > > ()
> > >
> > > "Jesse" <Jesse@discussions.microsoft.com> wrote in message
> > > news:5BA46BAC-7F8A-4349-8BE2-DE6F4B198CAC@microsoft.com...
> > > > Unfortunately this does not work.  I have tried redirecting in the
> > > > application_error event but for this particular exception, it seems
> that
> > > > asp.net just ignors everything and redirects to the "can't find
server
> or
> > > dns
> > > > error" page.  I have customErrors setup in web.config and that seems
> to be
> > > > ignored as well.
> > > >
> > > > Is there any way we can get microsoft to give us a definitive
> explanation
> > > on
> > > > this?  Are we basically just stuck displaying an unfriendly page to
> the
> > > user
> > > > that doesn't give them any clue about what happened?
> > > >
> > > > Jesse
> > > >
> > > > "Paul Glavich [MVP - ASP.NET]" wrote:
> > > >
> > > > > You should be able to handle this in the Application_Error event
in
> the
> > > > > Global.asax. The code below just shows some example code
> > > > >
> > > > > void Application_Error(object sender, EventArgs e)
> > > > > {
> > > > >     SomeStringVar = .Server.GetLastError.Message();
> > > > >     Server.Transfer("Errors.aspx")
> > > > >     Server.ClearError()
> > > > > }
> > > > >
> > > > > You could also have a web.config setting that captures that
> particular
> > > Http
> > > > > error number and redirects accordingly. Something like :-
> > > > > <configuration>
> > > > >    <system.web>
> > > > >       <customErrors defaultRedirect="GenericError.htm"
> > > > >                     mode="RemoteOnly">
> > > > >          <error statusCode="500"
> > > > >                 redirect="InternalError.htm"/>
> > > > >       </customErrors>
> > > > >    </system.web>
> > > > > </configuration>
> > > > >
> > > > > You could change (or add another entry) to the '500' for whatever
> error
> > > code
> > > > > you want.
> > > > >
> > > > >
> > > > >
> > > > > -- 
> > > > > - Paul Glavich
> > > > > Microsoft MVP - ASP.NET
> > > > >
> > > > >
> > > > > "moondaddy" <moondaddy@nospam.com> wrote in message
> > > > > news:O%23lzXrXYEHA.3988@tk2msftngp13.phx.gbl...
> > > > > > I have an application where users need to upload images and in
my
> > > > > web.config
> > > > > > file I have a setting like this:
> > > > > >
> > > > > > <httpRuntime maxRequestLength="512" />
> > > > > >
> > > > > > Which restricts image larger than 500k from being uploaded.  I'm
> also
> > > > > using
> > > > > > the HtmlInputFile control to do the uploading.  My problem is
that
> > > when
> > > > > the
> > > > > > user's file size exceeds 512k, the page immediately redirects to
> the
> > > "The
> > > > > > page cannot be displayed" error page which is very confusing.
The
> use
> > > > > will
> > > > > > think that their image is corrupt, or the website has a nasty
bug
> in
> > > it.
> > > > > > The way this should be handled is instead of showing the nasty
> "The
> > > page
> > > > > > cannot be displayed" page, show a friendly page telling the user
> that
> > > they
> > > > > > exceeded the file limit and to upload a smaller image.
> > > > > >
> > > > > > Is there a way to intercept this and do a redirect?  and if not,
> is
> > > there
> > > > > > any other way to handle this elegantly?
> > > > > >
> > > > > > -- 
> > > > > > moondaddy@nospam.com
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>