C# Response.WriteFile vs Response.TransmitFile filesize issues....

Question

I have a 5Mb pdf on the server dowloading this file using a writeFile gives me a 15Mb download, where as the transmitfile gives the correct 5Mb filesize...

Is this due to some sort of uncompression into memory on the server for the writeFile? Just wonder if anyone had seen the same thing happening...

(ps only noticed it since we went to iis7??)

code being...

if (File.Exists(filepath))
{
    HttpContext.Current.Response.Clear();
    HttpContext.Current.Response.ContentType = "application/octet-stream";
    HttpContext.Current.Response.AddHeader("content-disposition","attachment;filename=\""+Path.GetFileName(filepath)+"\"");
    HttpContext.Current.Response.AddHeader("content-length", new FileInfo(filepath).Length.ToString());

    //HttpContext.Current.Response.WriteFile(filepath);
    HttpContext.Current.Response.TransmitFile(filepath);

    HttpContext.Current.Response.Flush();
    HttpContext.Current.Response.Close();
}

Answer 1

TransmitFile - Writes the specified file directly to an HTTP response output stream without buffering it in memory.

WriteFile - Writes the specified file directly to an HTTP response output stream.

I would say the difference occurs because Transmit file doesn't buffer it. Write file is using buffering (Afiak), basically temporarily holding the data before transmitting it, as such it cannot guess the accurate file size because its writing it in chunks.

Answer 2

Thanks, Thought as much... but 15Mb vs 5Mb!! that seems a little too different. I did think that it might be a compressed pdf in some way... and that buffering it into memory might uncompress before sending?

Using fileinfo to get the length obviously just reports the 5Mb actual filesize.

It only became an issue as we moved to a cloud environment and bandwidth is now a chargeable entity :-(

And was quite tricky to trace down as the dev server didn't have the issue... and the only real difference was iis6 on dev and iis7 on live...