7

私たちのアプリケーションのユーザーは、日中に少なくとも2秒に1回添付ファイルをダウンロードします。

前のシナリオ：

ユーザーが添付ファイルをダウンロードした後、Response.End（）を使用してクライアントへの接続を中止していました。パフォーマンスの問題が発生したため、例外のログ記録を開始しました。最も繰り返されたものの1つは、スレッドアボート例外でした。Webサービスから添付ファイルを取得しているため、クリーンアップを実行する必要があり、try-catch-finallyブロックでクリーンアップを実行しました。調査の結果、Response.End（）以降のコードはfinallyブロックであっても実行されないことがわかりました。そうですか？

現在のシナリオ：

Response.End（）が有害であり、本当に必要な場合にのみ使用する必要があるというスタックオーバーフローのスレッドを読んだので、代わりにHttpContext .... CompleteRequest（）を使用することにしました。このコードを使用すると、必要なクリーンアップが実行されますが、レンダリングされたhtmlは、ダウンロードされた添付ファイルに追加されます。同じ記事で提案されているRenderとRaisePostBackEventをオーバーライドしようとしましたが、問題は解決しません。この問題を解決する方法についてのアイデアは役に立ちます。

コード：

HttpContext.Current.Response.Clear();

Response.ClearContent();

Response.ClearHeaders();

Response.AddHeader("Content-Disposition", "attachment; filename=" +   
filename);
Response.AddHeader("Content-Length", fileContent.Length.ToString());
Response.ContentType = "application/octet-stream";
Response.BinaryWrite(fileContent);
Response.Flush();
4

2 に答える 2

7

Response.End内部的に をスローしThreadAbortExceptionてリクエストを強制終了します。何らかのクリーンアップが必要な場合は、 の呼び出しが行われる前にResponse.Endこれを行う必要があります。

Response.Redirectまた、try / catch ブロックとResponse.Endうまくやり取りできません。したがって、あなたの状況では、すべてのロジックを try / catch で応答ストリームに書き込み、Response.End最後に単にブロックを呼び出す必要があります。

于 2012-05-15T15:35:14.437 に答える
1

古いQ、それが役立つかどうかはわかりませんが、ブラウザに配信するPDFファイルを作成するときは、基本的にあなたの例と同じです。ただし、処理の最後には、次のようになります。

    Response.OutputStream.Flush()
    Response.OutputStream.Close()
    Response.End()

基本的に .Close() の追加。本番環境では問題なく動作するようです。

Ed: これも見つけて、Close(): Is Response.End() は有害と見なされますか?

あなたの問題に対する別のアプローチは、単純に Page_PreRender() をオーバーライドし、そこにコンテンツ配信コードを配置することです (これは機能的に意味があります)。そうすれば、不要な HTML はまったく得られず、Response.End() はまったく必要ありません。

于 2013-01-07T09:58:30.347 に答える