K
kierenj
Hi,
I'm trying to send a zipfile to a client using Content-Disposition:
attachment. Done it before and it works fine.
My code is below:
context.Response.Buffer = false;
System.IO.MemoryStream stream =
ArchiveUtil.CreateArchive(new string[] { "c:\\windows\
\setuplog.txt" } , new string[] { "setuplog.txt" });
context.Response.ContentType = "application/octet-
stream";
context.Response.AddHeader("Content-Disposition",
"attachment; filename=\"test-download.zip\"");
context.Response.AddHeader("Content-Length",
stream.Length.ToString());
byte[] buffer = new byte[1024];
long byteCount;
int total = 0;
while ((byteCount = stream.Read(buffer, 0,
(int)buffer.Length)) > 0)
{
if (context.Response.IsClientConnected)
{
context.Response.OutputStream.Write(buffer, 0, (int)byteCount);
total += (int)byteCount;
context.Response.OutputStream.Flush();
}
else
break;
}
stream.Close();
context.Response.End();
(The MemoryStream is fine and valid - saving the contents to disk
works fine.)
The problem is the stream contains around 60k-ish bytes, but IE/
Firefox/whatever only gets about 30k. At the end of the code, "total"
contains the correct value (60k).
The code above infact causes the download to 'hang' in IE - because
Content-Length is set to 60k. It is only by removing the Content-
Length header that I actually get a file in IE I can open/save; and
it's corrupted and only 30k.
Looking at the corrupt file in a hex editor, it has "PK" and the
setuplog.txt filename near the beginning and again near the end.
Comparing this with the "correct" zip file, this is the same! It is
NOT simply truncated. It's like the binary data in the file is being
transformed somehow?
Putting the code in a clean/fresh ASP.NET app, it annoyingly works
fine. As far as I know there are no weird settings in the main app
where this code sits.
After looking carefully at the session with Fiddler (comparing the
working miniapp with this broken one), apart from the obvious
difference that the wrong number of bytes are actually sent down the
socket, the non-working code sends using CHUNKED content encoding -
the working one doesn't. I have no idea why this is or if it might be
a cause/effect of the problem?
Does anyone have any ideas at all? Heard of the binary data being
transformed in some way before? This is driving me crazy... any input
appreciated!
Thanks
I'm trying to send a zipfile to a client using Content-Disposition:
attachment. Done it before and it works fine.
My code is below:
context.Response.Buffer = false;
System.IO.MemoryStream stream =
ArchiveUtil.CreateArchive(new string[] { "c:\\windows\
\setuplog.txt" } , new string[] { "setuplog.txt" });
context.Response.ContentType = "application/octet-
stream";
context.Response.AddHeader("Content-Disposition",
"attachment; filename=\"test-download.zip\"");
context.Response.AddHeader("Content-Length",
stream.Length.ToString());
byte[] buffer = new byte[1024];
long byteCount;
int total = 0;
while ((byteCount = stream.Read(buffer, 0,
(int)buffer.Length)) > 0)
{
if (context.Response.IsClientConnected)
{
context.Response.OutputStream.Write(buffer, 0, (int)byteCount);
total += (int)byteCount;
context.Response.OutputStream.Flush();
}
else
break;
}
stream.Close();
context.Response.End();
(The MemoryStream is fine and valid - saving the contents to disk
works fine.)
The problem is the stream contains around 60k-ish bytes, but IE/
Firefox/whatever only gets about 30k. At the end of the code, "total"
contains the correct value (60k).
The code above infact causes the download to 'hang' in IE - because
Content-Length is set to 60k. It is only by removing the Content-
Length header that I actually get a file in IE I can open/save; and
it's corrupted and only 30k.
Looking at the corrupt file in a hex editor, it has "PK" and the
setuplog.txt filename near the beginning and again near the end.
Comparing this with the "correct" zip file, this is the same! It is
NOT simply truncated. It's like the binary data in the file is being
transformed somehow?
Putting the code in a clean/fresh ASP.NET app, it annoyingly works
fine. As far as I know there are no weird settings in the main app
where this code sits.
After looking carefully at the session with Fiddler (comparing the
working miniapp with this broken one), apart from the obvious
difference that the wrong number of bytes are actually sent down the
socket, the non-working code sends using CHUNKED content encoding -
the working one doesn't. I have no idea why this is or if it might be
a cause/effect of the problem?
Does anyone have any ideas at all? Heard of the binary data being
transformed in some way before? This is driving me crazy... any input
appreciated!
Thanks
