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
{
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 said:
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.
redirect
server
in
The
bug