Bad Gift from MS in December 2006

  • Thread starter Thread starter Just D.
  • Start date Start date
J

Just D.

Great thanks to MS, the code written several months ago and working just
perfectly before December 2006 suddenly stopped working generating errors or
downloading trash instead of real data. Nice security patch, guys!

The code in the aspx page codebehind file is very simple.

Response.Clear();
Response.Buffer = true;
Response.Expires = 0;
Response.ContentType = "application/zip";
Response.AddHeader("Content-Disposition",
"attachment;filename=SomeFileName.zip");
Response.AddHeader("Content-transfer-encoding", "binary");
Response.BinaryWrite(SomeByteArrayBuffer);
Response.Flush();

It was working just great, but now it returns corrupted binary files. Zip
can't open them at all, WinRar complains about "unexpected end of archive"
but nevertheless shows the content of the archived file. Another one
problem - I provide the link to our WinApp to let the client download and
install it. When I click this link working on localhost it works perfectly
and I can DL this file.
When I upload the same app to our working server, regardless of VPN
connection, trusted web site list or whatever I'm not able even to download
the WinApp file, when I click the link on my own aspx page the IE starts
downloading it, but the actual size of this file is longer than the real
size of the real app located on the server. After this try the IE complaints
that it's not able to download the file, the file doesn't exist or something
else. BSH! It was working just perfectly a month ago! What M$ did to crash
everything down? Is it really called critical system update, permission
issue or smth like that? Anyway, how can we get the same code working before
to work again? As usual M$ never provides example or explanations, just bugs
calling them fixes.

Just D.
 
My first move would be rather to save the file and perform a size (and if
applicable byte) comparison (for example using the "fc" command)...

I would also try :
- to remove the content-transfer-encoding header
- what if using an already done stored on disk zip file ?
- you could also use Response.End instead of flush in case you have some
extra bytes written after the file

Patrice
 
1. Respond.End() doesn't help and actually it's even worst.
2. I found the real reason. Small files are still working. Since I'm
transferring XML files the compression ratio is terrible and I finally
notices that the files over 4 MBytes, in my case 6 Mbytes are coming
corrupted. IIS has a limitation of 4 MBytes to the attached files, fixable
in Machine.Config file. I didn't play deeper yet, but I got a very strong
feeling that MS added a context control for the archives attached by IIS and
the uncompressed file just overruns the buffer available for this operation.
Repeat again - smaller files works perfectly.

Just D.
 
Back
Top