O que está causando “Estado da sessão criou um ID de sessão, mas não pode salvá-lo porque a resposta já foi liberado pelo aplicativo.”

Question

Estou recebendo este falha intermitentemente.

Eu encontrei este link que resume muito bem o que eu era capaz de encontrar no Google: http://www.wacdesigns.com/2009/02/03/session-state-has-created-a-session-id-but- não pode-save-lo porque-o-resposta-era-já-corada-by-the-application /

Basicamente, ele diz que você pode tentar definir a configuração DisplayWhenNewSession configuração web, ou tentar chutar a coisa estado de sessão para a vida, obtendo o Session.SessionID no Session_OnStart.

Mas alguém:

a) tem uma explicação para este

ou ainda melhor, b) ter uma correção experimentadas e testadas

Eu percebo que eu não posso lavar a resposta depois de fazer qualquer coisa que possa afetar o cabeçalho de resposta HTTP. Se eu fizesse isso, iria causar um erro cada vez , mas esta é intermitente. O SessionID deve certamente ser criado por ASP.NET no início da resposta página automaticamente, antes de qualquer coisa na página ASPX ou no Page_Load (que é onde todos os meus rubores são chamados).

Update: Na reflexão Sei que isso está acontecendo quando streaming de um baixo arquivo para o navegador. A maioria dos navegadores são realmente procurar bots motor. Eu posso recriar este erro ao iniciar um download e, em seguida, fechar o navegador, então, presumivelmente, os navegadores não estão à espera de que o download completo antes de cancelar a operação de download. Também já vi isso em outras páginas, normal, mas 99% do tempo é páginas de download.

Answer 1

Eu tenho!

No arquivo global.asax que você faça o seguinte:

void Session_Start(object sender, EventArgs e) 
{
    // Code that runs when a new session is started
    string sessionId = Session.SessionID;
}

Assim fácil. Ele funciona!

Answer 2

Este erro parece surgir quando:

• O início aplicação

• Você está usando um Global.asax mesmo se você está fazendo algo nos eventos Session_Start / Fim ou não

• A sua aplicação forças o rubor da resposta muito em breve

• Você não está usando a sessão antes de o flush

É levantada pelo estado da sessão quando tentar salvar a sessionID na versão:

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)

Eu acredito que a presença de Global.asax faz com que o ID da sessão para ser salvo na liberação pelo SessionStateModule (final?), Mesmo se nenhuma sessão têm sido utilizados em vez de HttpSessionState quando SessionID é chamado.

É a razão pela qual string sessionId = Session.SessionID;. truque evitar o problema

Eu acho que só aparece no arranque da aplicação por causa de comportamentos de inicialização.

Solutions / truques :

• Evite rubor em Page_Load como já disse

• desactivar o estado da sessão na página (EnableSessionState)

• Use o truque de sessão antes de o flush

• Use Response.End () no lugar de .Flush () se você não se preocupam com os erros que podem ocorrer após o seu flush

Answer 3

Eu acredito que a questão aqui pode ser exatamente o que você está fazendo algo para a saída causa página durante Page_Load, que, de acordo com o ASP.NET Página Lifecycle Overview é muito antes do estágio de processamento.

Certifique-se de que você nunca fazer nada que possa provocar a saída página até depois da fase PreRender.

Answer 4

Tendo acabado de executar para esse problema sozinho, eu pensei que iria partilhar as minhas conclusões.

O web.config definição DisplayWhenNewSession é irrelevante, uma vez que só se aplica a um CustomControl especial no CodePlex (desculpe, eu perdi o link).

A outra sugestão parece funcionar por inicializar o SessionId cedo. Cavei no código usando reflector e não conseguia ver como isso impediu o erro aqui, mas certamente funcionou para nós!

Como a maioria das pessoas que parecem executar para esse bug, não estamos chamando explicitamente Response.Flush () em qualquer lugar do aplicativo. Também estamos usando MVC, para o registro.

Answer 5

Eu reconheço isso é muito velho, mas eu encontrei um outro motivo para o erro que pode se aplicar a outros. Se você estiver usando MVC (eu estava usando MVC 4 com .Net 4.0) e você definir as páginas para não tampão usando o elemento web.config

<pages buffer="false">    

Então, se no seu código você tentar enviar dados para o objeto de sessão, pode estar arriscando recebendo este erro se a página tinha começado a prestação antes de sua visão da criança ou ação realizando o acesso estado da sessão.

Em tais casos, você pode corrigir o erro, alterando a configuração de buffer acima de verdade. Alternativamente, mova o código de acesso da sessão à vista principal e não em um / view ação criança criança.