Symptoms are very like C# BinaryWrite over SSL but my code already complies with all of the proposed solutions. This behaviour was manifest on Edge, IE11 and Chrome at the time of writing. Code that worked fine over HTTP broke when delivered over HTTPS.
private void RenderPdfToResponse(bool asDownload, byte[] documentBytes)
{
Response.BufferOutput = true;
Response.ClearContent();
Response.ClearHeaders();
Response.AddHeader("Cache-control", "no-store");
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Length", documentBytes.Length.ToString());
if (asDownload)
Response.AddHeader("Content-Disposition",
string.Format("attachment; filename=export{0:yyyyMMddHHmmss}.pdf", DateTime.UtcNow));
Response.BinaryWrite(documentBytes);
Response.Flush();
HttpContext.Current.ApplicationInstance.CompleteRequest();
}
The problem is at the browser. Delivered binary content that should be saved into a file is instead rendered in the browser window. Interception with debug tools and saving into a file allows verification that the delivered bytes form a valid PDF.
Given that all the suggestions of the referenced question are already in effect, and the problem is browser behaviour, what options remain?
Consulting https://www.rfc-editor.org/rfc/rfc6266 we find that the filename portion is optional. Experimentally specifying
Response.AddHeader("Content-Disposition", "attachment");
causes all major browsers to pop a Save As dialog with the name export-pdf.pdf
which is apparently derived from the name of the ASPX file and the mime type.
At this point I was asked to ship. I hope someone finds this helpful.