"세션 상태에서 세션 ID를 만들었지 만 응용 프로그램에서 이미 응답을 플러시했기 때문에 저장할 수 없습니다."의 원인이됩니다.
이 결함이 간헐적으로 발생합니다.
Google에서 찾은 내용을 상당히 잘 요약 한 링크를 찾았습니다. http://www.wacdesigns.com/2009/02/03/session-state-has-created-a-session-id-but- 응답이 이미 응용 프로그램에 의해 플러시 되었기 때문에 저장할 수 없습니다.
기본적으로 웹 구성 설정 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의 특정 사용자 지정 컨트롤에만 적용되므로 관련이 없습니다 (죄송합니다. 링크를 잃어 버렸습니다).
다른 제안은 SessionId를 일찍 초기화하여 작동하는 것으로 보입니다. 나는 Reflector를 사용하여 코드를 파헤 쳤고 이것이 여기서 오류를 어떻게 방지하는지 잘 알 수 없었지만 확실히 우리에게는 효과가있었습니다!
이 버그를 겪는 것처럼 보이는 대부분의 사람들과 마찬가지로 우리는 앱 어디에서나 Response.Flush ()를 명시 적으로 호출하지 않습니다. 우리는 또한 기록을 위해 MVC를 사용하고 있습니다.
나는 이것이 매우 오래되었다는 것을 알고 있지만 다른 사람들에게 적용될 수있는 오류에 대한 또 다른 이유를 발견했습니다. MVC (.Net 4.0과 함께 MVC 4를 사용 중임)를 사용하고 web.config 요소를 사용하여 페이지를 버퍼링하지 않도록 설정 한 경우
<pages buffer="false">
그런 다음 코드에서 세션 개체로 데이터를 푸시하려고하면 페이지가 자식보기 또는 세션 상태 액세스를 수행하는 작업 전에 렌더링을 시작했다면이 오류가 발생할 위험이 있습니다.
이러한 경우 위의 버퍼 설정을 true로 변경하여 오류를 수정할 수 있습니다. 또는 세션 액세스 코드를 하위 작업 / 하위보기가 아닌 기본보기로 이동합니다.
'programing' 카테고리의 다른 글
| 인간 게놈을 저장하려면 얼마나 많은 저장 공간이 필요합니까? (0) | 2020.10.27 |
|---|---|
| /Library/Frameworks/Python.framework에 대한 Homebrew Brew 의사 경고 (brew의 Python이 설치된 경우에도) (0) | 2020.10.27 |
| std :: string과 std :: basic_string의 차이점은 무엇입니까? (0) | 2020.10.27 |
| GHCi를 사용할 때 함수에 대한 명시 적 유형 선언을 제공하는 방법은 무엇입니까? (0) | 2020.10.27 |
| -webkit-margin은 텍스트에 원하지 않는 여백을 추가합니다. (0) | 2020.10.27 |