この障害が断続的に発生しています。
Googleで見つけることができたものをかなりよく要約したこのリンクを見つけました: http://www.wacdesigns.com/2009/02/03/session-state-has-created-a-session- id-but-cannot-save-it-because-the-response-was-already-flushed-by-the-application /
基本的には、Web構成設定DisplayWhenNewSessionを設定するか、Session_OnStartでSession.SessionIDを取得することでセッション状態をキックすることができます。
しかし、誰もが:
a)これについて説明してください
さらに良いことには、b)試行錯誤の修正を行います
Http応答ヘッダーに影響するようなことを行った後、応答をフラッシュできないことに気付きました。これを行うと、エラーが毎回発生しますが、これは断続的です。 SessionIDは、ASPXページまたはPage_Load(すべてのフラッシュが呼び出される場所)の前に、ページ応答の開始時にASP.NETによって必ず作成される必要があります。
更新:振り返ってみると、ファイルをブラウザにストリーミングするときにこれが起こっていることに気付きました。ほとんどのブラウザは、実際には検索エンジンボットです。ダウンロードを開始してからブラウザーを閉じることにより、このエラーを再現できます。したがって、ブラウザーはダウンロード操作をキャンセルする前にダウンロードの完了を待機していないと考えられます。これは他の通常のページでも見ましたが、99%がダウンロードページです。
私が持っています!
Global.asaxファイルでこれを行います:
void Session_Start(object sender, EventArgs e)
{
// Code that runs when a new session is started
string sessionId = Session.SessionID;
}
とても簡単。できます!
このエラーは次の場合に表示されるようです:
アプリケーション開始
Session_Start/Endイベントで何かをしている場合でも、Global.asaxを使用している場合
アプリケーションが応答のフラッシュをすぐに強制します
フラッシュの前にセッションを使用していません
リリース時にsessionIDを保存しようとすると、セッション状態によって発生します。
System.Web.SessionState.SessionIDManager.SaveSessionID(HttpContext context, String id, Boolean& redirected, Boolean& cookieAdded)
System.Web.SessionState.SessionStateModule.CreateSessionId()
System.Web.SessionState.SessionStateModule.DelayedGetSessionId()
System.Web.SessionState.SessionStateModule.ReleaseStateGetSessionID()
System.Web.SessionState.SessionStateModule.OnReleaseState(Object source, EventArgs eventArgs)
System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Global.asaxが存在すると、SessionIDが呼び出されたときにHttpSessionStateの代わりにセッションが使用されなかった場合でも、SessionStateModuleによってセッションIDがリリース時に保存される(後期?)と考えられます。
それが理由です string sessionId = Session.SessionID; 問題を回避するトリック。
初期化動作のため、アプリケーションの起動時にのみ表示されると思います。
ソリューション/トリック :
既に述べたようにPage_Loadでのフラッシュを避けます
ページのセッション状態を非アクティブ化します(EnableSessionState)
フラッシュの前にSessionIDトリックを使用します
フラッシュ後に発生する可能性のあるエラーを気にしない場合は、.Flush()の代わりにResponse.End()を使用します
ここでの問題は、あなたがPage_Load
。これは、 ASP.NETページライフサイクルの概要 によると、レンダリング段階のかなり前です。
PreRender
ステージの後まで、ページ出力をトリガーする可能性のあることは絶対にしないでください。
自分でこの問題にぶつかったので、自分の発見を共有したいと思いました。
Web.config設定DisplayWhenNewSessionは、Codeplexの1つの特定のカスタムコントロールにのみ適用されるため、無関係です(すみませんが、リンクを失いました)。
もう1つの提案は、SessionIdを早期に初期化することで機能するようです。 Reflectorを使用してコードを掘り下げたところ、ここでエラーがどのように防止されたかはわかりませんでしたが、確かに機能しました!
このバグに遭遇したと思われるほとんどの人と同様に、アプリのどこでもResponse.Flush()を明示的に呼び出していません。レコードにはMVCも使用しています。
私はこれが非常に古いことを認識していますが、他の人に当てはまるかもしれないエラーの別の理由を見つけました。 MVCを使用している場合(.Net 4.0でMVC 4を使用していた場合)、web.config要素を使用してページをバッファリングしないように設定する場合
<pages buffer="false">
コードでセッションオブジェクトにデータをプッシュしようとすると、子ビューまたはセッションステートアクセスを実行するアクションの前にページのレンダリングが開始された場合、このエラーが発生する危険があります。
このような場合、上記のバッファー設定をtrueに変更することでエラーを修正できます。または、セッションアクションコードを、子アクション/子ビューではなくメインビューに移動します。