http://blogs.msdn.com/b/ieinternals/archive/2012/07/16/content-length-and-transfer-encoding-validation-in-ie10-download-manager-couldnt-be-downloaded-retry-cancel.aspx
Which led me to understand that there was a problem with the way we had written our export code.
This is what we had:
string strFileName = lblRiverName.Text;
Response.ContentType = "application/vnd.ms-excel";
Response.AddHeader("Content-Disposition", "attachment; filename=" + strFileName + ".xls");
Response.Write("...output here...");
Response.Flush();
Response.Close();
Response.End();
After reading the msdn blog post, I see that don't in fact want to call Response.Close(). It also sounded like we shouldn't call Response.End() either. So I commented both of those lines out and traded one problem for another.
Now I was getting what seemed to be the initial html of the web page saved into the export file! Very strange. After reading more blogs and docs, I decided that perhaps Response.End() was important after all, contrary to what many folks seemed to say. That did the trick. So in the end all that needed to be done was to comment out the Response.Close():
string strFileName = lblRiverName.Text;
Response.ContentType = "application/vnd.ms-excel";
Response.AddHeader("Content-Disposition", "attachment; filename=" + strFileName + ".xls");
Response.Write("...output here...");
Response.Flush();
//Response.Close();
Response.End();
Another win for Microsoft! (tic)
