By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,190 Members | 2,204 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,190 IT Pros & Developers. It's quick & easy.

Some IEs crash when using Response.WriteFile()

P: n/a
We are building a webapplication but keep hitting a wall: The user can
download files but we need to check if they are authorized to do so. We do
this with a download-page and use the following code:

public void ProcessRequest(HttpContext context)
{
context.Response.Clear();
context.Response.AppendHeader("Content-Disposition", "attachment;
filename=test.txt");
context.Response.AppendHeader("Content-Length", "4");
context.Response.ContentType = "application/octet-stream";
context.Response.WriteFile("c:\\test.txt");
context.ApplicationInstance.CompleteRequest();
}

The problem is that on some browsers (2 out 3 tested Windows 2000-machines,
1 out of 4 tested Windows XP-machines. All with IE6) just crash when the
download is finished. If we choose to open the file instead of saving it in
the download-dialog everything works fine and we're able to save the file to
disc from notepad. The test-machines are able to download files from other
webapplications.

We removed all code but the above. We did use a FileInfo-object to get the
length but to avoid all variables we hardcoded the file-length of test.txt.
We tried with an empty aspx-file and the above code in the codebehind-file.
Now we are using an IHttpHandler with the same code and same result.

We have tried to open the file and use Response.BinaryWrite with the same
result. We have tried to different combinations of the headers and leaving
one or both out. We have tried with Application/x-msdownload instead of
application/octet-stream.
We have tried using Response.End() instead of
ApplicationInstance.CompleteRequest();

Why is IE crashing? What can we do to avoid it? Has anyone else experienced
this problem?
Nov 22 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
The code was running in an iframe. We changed the target to "_parent" and now
it all works. Seems to be some combination of an iframe-problem,
security-settings in the browser and maybe smartnavigation.

"Claus Pedersen" wrote:
We are building a webapplication but keep hitting a wall: The user can
download files but we need to check if they are authorized to do so. We do
this with a download-page and use the following code:

public void ProcessRequest(HttpContext context)
{
context.Response.Clear();
context.Response.AppendHeader("Content-Disposition", "attachment;
filename=test.txt");
context.Response.AppendHeader("Content-Length", "4");
context.Response.ContentType = "application/octet-stream";
context.Response.WriteFile("c:\\test.txt");
context.ApplicationInstance.CompleteRequest();
}

The problem is that on some browsers (2 out 3 tested Windows 2000-machines,
1 out of 4 tested Windows XP-machines. All with IE6) just crash when the
download is finished. If we choose to open the file instead of saving it in
the download-dialog everything works fine and we're able to save the file to
disc from notepad. The test-machines are able to download files from other
webapplications.

We removed all code but the above. We did use a FileInfo-object to get the
length but to avoid all variables we hardcoded the file-length of test.txt.
We tried with an empty aspx-file and the above code in the codebehind-file.
Now we are using an IHttpHandler with the same code and same result.

We have tried to open the file and use Response.BinaryWrite with the same
result. We have tried to different combinations of the headers and leaving
one or both out. We have tried with Application/x-msdownload instead of
application/octet-stream.
We have tried using Response.End() instead of
ApplicationInstance.CompleteRequest();

Why is IE crashing? What can we do to avoid it? Has anyone else experienced
this problem?

Nov 22 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.