How to intercept error when httpRuntime maxRequestLength is exceded.

Check your web.config for Trace element, if the trace element is set to
true in web.config or in the page directive than Application_Error won't
fire.. Give it a try

-RK


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

R K

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" <> wrote in message
> news:O%...
> > 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?
> >
> > --
> >
> >
> >
>
>
>

=?Utf-8?B?SmVzc2U=?=

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
(http://hdave.blogspot.com)

"Jesse" <> wrote in message
news:5BA46BAC-7F8A-4349-8BE2-...
> 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" <> wrote in message
> > news:O%...
> > > 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?
> > >
> > > --
> > >
> > >
> > >
> >
> >
> >

Hermit Dave

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" <> wrote in message
> news:5BA46BAC-7F8A-4349-8BE2-...
> > 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" <> wrote in message
> > > news:O%...
> > > > 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?
> > > >
> > > > --
> > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
>

=?Utf-8?B?SmVzc2U=?=

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" <> wrote in message
news:B8879A40-C914-4C9A-B9EF-...
> 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" <> wrote in message
> > news:5BA46BAC-7F8A-4349-8BE2-...
> > > 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" <> wrote in message
> > > > news:O%...
> > > > > 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?
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >

Hermit Dave

was it of any help ?

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)
"Hermit Dave" <> wrote in message
news:...
> 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" <> wrote in message
> news:B8879A40-C914-4C9A-B9EF-...
> > 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" <> wrote in message
> > > news:5BA46BAC-7F8A-4349-8BE2-...
> > > > 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" <> wrote in message
> > > > > news:O%...
> > > > > > 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?
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>

Hermit Dave