I updated my download control a bit tonight - fixing (hopefully) a bug in the download process.  I've had many people download files from the site and not a single person has sent me the feedback that it wasn't working though all other indications are that it's failing.  For instance, a user attempts to download a file multiple times in a few minute span, etc.  It was working fine in my test environment but apparently it wasn't working correctly from the actual server.

When you request a download you get an email with a confirmation number and a direct link back to the download.  Well, I had an HTTP handler set to receive the request that consists of the download identifier along with the confirmation code.  However a bug (I'm presuming it's in IE) misinterprets the HTTP Headers in the response and it attempts to save the file with the useless name of the CONFIRMATIONCODE.dspx rather than the appropriate name (.dspx is the extension I use to identify my 'Devstone Server Page' handler).

My code resembles the following, where info is a class instance that identifies the requested download:

HttpResponse res = context.Response;
res.Cache.SetCacheability(HttpCacheability.Private);
res.ContentType = "application/download";
res.AppendHeader("Content-Disposition", "attachment; filename=" + info.FileName);
res.WriteFile(info.GetDirectServerPath());

Can anyone see anything blatently wrong with this code?  I've had it work many times (even occasionally from the production site), but for the most part it doesn't seem to work from a direct link - however, it does work with I perform a Response.Redirect() to the url.  I'll look into the differences to see what might be happening.

As a temporary patch to the problem, when you attempt to download a file, you're asked to provide your confirmation number.

I apologize for the inconvenience.