Response.Endの（対ApplicationInstance.CompleteRequestの好奇心が強い行動に（））

Question

私は、ファイルは次のコードでダウンロードされたときにことを観察した：

HttpContext.Current.Response.ContentType = "application/pdf"; 
HttpContext.Current.Response.AddHeader("content-disposition", "attachment;filename=~/test.pdf"); 
HttpContext.Current.Response.WriteFile("~/test.pdf"); 
HttpContext.Current.ApplicationInstance.CompleteRequest(); 

私たちは、以下のコードを使用した場合よりも大きなファイルを取得：最初のケースでは、ファイル、ファイルがダウンロードされたページのソースコードの終了後に、追加されるため

HttpContext.Current.Response.ContentType = "application/pdf"; 
HttpContext.Current.Response.AddHeader("content-disposition", "attachment;filename=~/test.pdf"); 
HttpContext.Current.Response.WriteFile("~/test.pdf"); 
HttpContext.Current.Response.End(); 

大きいサイズです。したがって、ダウンロードされたすべてのファイルは、ソースコードの長さに等しい固定バイト数で増加します。 PDFの場合、Adobe Readerで開くと、余分なバイトは変更として解釈され、閉じると変更が保存されます。その後、pdfはより小さなサイズを回復します。ファイルが16進エディターと比較される場合は、同じではあるがサイズが異なり、最後にEOFマークの後にページソースコードのバイトが表示されることを警告します。

物理ファイルの代わりにMemoryStreamを使用し、Response.BinaryWrite（）などのバイト配列を送信する場合も同様です。

この現象の原因は何か、どのように修正できますか？

Answer 1

解決策が見つかりました。 Response.SupressContent（）でHTMLを添加EOFマークが抑制され、ファイルのPDFがソースと同一である後：

HttpContext.Current.Response.ContentType = "application/pdf"; 
HttpContext.Current.Response.AddHeader("content-disposition", "attachment;filename=~/test.pdf"); 
HttpContext.Current.Response.WriteFile("~/test.pdf"); 
Response.Flush(); 
Response.SuppressContent = true; 
HttpContext.Current.ApplicationInstance.CompleteRequest();