세션 상태가 세션 ID를 생성했지만 응답이 응용 프로그램에 의해 이미 플러시되었기 때문에 저장할 수 없습니다."를 발생시키는 원인

세션 상태가 세션 ID를 생성했지만 응답이 응용 프로그램에 의해 이미 플러시되었기 때문에 저장할 수 없습니다."를 발생시키는 원인

간헐적으로 이 고장이 납니다.

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/

기본적으로 웹 구성 설정을 시도할 수 있다고 표시됩니다.New Session을 실행하거나 Session을 실행하여 Session 상태를 활성화합니다.Session_OnStart의 SessionID입니다.

하지만 누군가가:

이것에 대한 설명이 있습니다.

또는 더 나은 것은 b) 시도되고 테스트된 해결책을 가지고 있다는 것입니다.

http response header에 영향을 주는 일을 한 후에는 응답을 플러시할 수 없다는 것을 알았습니다.이렇게 하면 매번 오류가 발생하지만 간헐적으로 발생합니다.세션ID는 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를 사용하고 있습니다.

• 응용 프로그램이 너무 빨리 응답을 플러시합니다.

• 플러시 전에 세션을 사용하지 않습니다.

세션을 저장하려고 할 때 세션 상태에 의해 발생합니다.릴리스 시 ID:

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가 있으면 세션 ID가 SessionStateModule(늦은 시간?)에 의해 릴리스될 때 저장된다고 생각합니다.세션 시 HttpSessionState 대신 사용된 세션이 없는 경우에도ID가 호출됩니다.

이는 string sessionId = Session이 되는 이유입니다.세션 ID. 트릭을 사용하여 문제를 방지합니다.

초기화 동작 때문에 애플리케이션 시작 시에만 나타나는 것 같습니다.

솔루션/트릭:

• 이미 말한 대로 Page_Load에서 플러시를 방지합니다.

• 페이지에서 세션 상태 비활성화(EnableSessionState)

• 세션 사용플러시 전 ID 트릭

• 응답을 사용합니다.대신 ()을 끝냅니다.플러시 후 발생할 수 있는 오류에 대해 신경 쓰지 않는 경우 플러시()

여기서의 문제는 정확히 당신이 페이지 출력을 유발하는 무언가를 하고 있다는 것일 수 있습니다.Page_LoadASP.NET 페이지 라이프사이클 개요에 따르면 이는 렌더링 단계보다 훨씬 이전입니다.

수 로 하지 .PreRender 무대.

저는 이 문제에 직접 부딪혔기 때문에 제 연구 결과를 공유하려고 생각했습니다.

web.config 설정 화면표시NewSession이 Codeplex의 특정 사용자 지정 컨트롤 하나에만 적용되므로 관련이 없는 경우(링크를 잃어버려서 죄송합니다).

다른 제안은 SessionId를 초기화함으로써 효과가 있는 것으로 보입니다.Reflector를 사용하여 코드를 파고들었는데 어떻게 이것이 오류를 방지하는지 잘 알 수 없었지만, 확실히 우리에게 효과가 있었습니다!

대부분의 사람들이 이 버그에 부딪히는 것처럼, 우리는 응답을 명시적으로 부르지 않습니다.앱의 아무 곳이나 플러시()합니다.우리는 또한 MVC를 참고로 사용하고 있습니다.

저는 이것이 매우 오래되었다는 것을 알고 있지만, 다른 사람들에게 적용될 수 있는 오류에 대한 다른 이유를 찾았습니다.MVC를 사용하는 경우 (MVC 4를 사용하고 있었습니다.)Net 4.0)을 사용하면 web.config 요소를 사용하여 페이지가 버퍼링되지 않도록 설정할 수 있습니다.

<pages buffer="false">    

그러면 코드에서 세션 개체에 데이터를 밀어넣으려고 할 경우, 세션 상태 액세스를 수행하는 하위 보기 또는 작업 이전에 페이지 렌더링이 시작된 경우 이 오류가 발생할 위험이 있습니다.

이러한 경우 위의 버퍼 설정을 true로 변경하여 오류를 해결할 수 있습니다.또는 세션 액세스 코드를 하위 작업/하위 보기가 아닌 기본 보기로 이동합니다.

언급URL : https://stackoverflow.com/questions/904952/whats-causing-session-state-has-created-a-session-id-but-cannot-save-it-becau