2009-05-25 18 views
61

Ho riscontrato questo errore a intermittenza.Cosa sta causando "Lo stato della sessione ha creato un ID di sessione, ma non è possibile salvarlo perché la risposta è già stata scaricata dall'applicazione."

Ho trovato questo link che riassume abbastanza bene quello che ero in grado di trovare su 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/

In sostanza si dice che si può provare a impostare l'impostazione DisplayWhenNewSession config web, o provare a calci la cosa lo stato della sessione nella vita ottenendo il Session.SessionID in Session_OnStart.

Ma qualcuno:

a) hanno una spiegazione per questo

o, meglio ancora, b) hanno un provato e testato correzione

mi rendo conto che non posso lavare la risposta dopo fare qualsiasi cosa che possa influenzare l'intestazione della risposta http. Se lo facessi, causerebbe un errore ogni volta ma questo è intermittente. SessionID deve essere creato sicuramente da ASP.NET all'inizio della risposta della pagina automaticamente, prima di qualsiasi cosa nella pagina ASPX o nel Page_Load (che è il punto in cui sono chiamati tutti i miei flush).

Aggiornamento: Riflettendo, mi rendo conto che ciò accade quando si esegue lo streaming di un file nel browser. La maggior parte dei browser sono in realtà motori di ricerca. Posso ricreare questo errore avviando un download e chiudendo il browser, quindi presumibilmente i browser non sono in attesa del completamento del download prima di annullare l'operazione di download. L'ho visto anche su altre pagine normali, ma il 99% delle volte si tratta di pagine di download.

+1

Ho esattamente lo stesso problema. L'unica ragione per cui l'ho visto è stato quando ho inserito la gestione delle eccezioni in Global.asax. È molto intermittente. Sarebbe bello se qualcuno sapesse la risposta a questo! –

+6

Il collegamento è ora interrotto :-( – Casebash

+0

Collegamento a Wayback Machine: https://web.archive.org/web/20090208233145/http://www.wacdesigns.it/2009/02/03/session-state-ha-creato-a-sessione-id-ma-non-salva-it-perché-la-risposta-era-già-svuotata-dall'applicazione/ – lorenzog

risposta

64

Ho!

nel file Global.asax si esegue questa operazione:

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

Così facile. Funziona!

+0

Si tratta di un metodo pubblico/protetto, poiché è privato, suppongo che debba essere protetto. Il campione è completo, il fatto che il sessionId non sia stato salvato, presumo sia soddisfacente - è l'innesco della creazione che è importante, giusto? –

+0

Grazie. Penso che in genere funzioni così, la contrassegnerò come risposta accettata, anche se non ne sono sicuro al 100%. Qualcuno può commentare per favore se trova un caso in cui questo non funziona? Grazie. –

+0

Ho semplicemente aggiunto questo metodo al mio file global.asax e mi sono liberato del mio messaggio di errore, che era lo stesso della domanda, grazie mille eitama! – vanhornRF

6

Credo che il problema qui potrebbe essere esattamente quello che stai facendo qualcosa per causare l'output della pagina durante Page_Load, che, secondo lo ASP.NET Page Lifecycle Overview è molto prima della fase di rendering.

Assicurarsi di non eseguire mai azioni che potrebbero attivare l'output della pagina fino a dopo lo stage PreRender.

+0

Grazie , Lo darò un'occhiata stasera. Non sei sicuro del motivo per cui sarebbe intermittente? –

+0

un Response.Write condizionato() in un evento inappropriato forse? –

3

Avendo appena imbattuto in questo problema, ho pensato di condividere le mie scoperte.

L'impostazione web.config DisplayWhenNewSession è irrilevante in quanto si applica solo a un particolare controllo personalizzato su Codeplex (mi spiace di aver perso il collegamento).

L'altro suggerimento sembra funzionare inizializzando la SessionId in anticipo. Ho scavato nel codice usando Reflector e non ho potuto vedere come questo ha impedito l'errore qui, ma sicuramente ha funzionato per noi!

Come la maggior parte delle persone che sembrano imbattersi in questo bug, non chiamiamo in modo esplicativo Response.Flush() in qualsiasi punto dell'app. Usiamo anche MVC, per la cronaca.

18

Questo errore sembra apparire quando:

  • L'applicazione Iniziamo

  • Stai utilizzando un Global.asax anche se si sta facendo qualcosa negli eventi Session_Start/fine o no

  • l'applicazione costringe il filo della risposta troppo presto

  • non stai utilizzando la Sessio n prima che il filo

Si è sollevata dallo stato della sessione quando si tenta di salvare il sessionID sul rilascio:

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) 

credo che la presenza di Global.asax fa sì che l'ID di sessione da salvare al rilascio da parte di SessionStateModule (in ritardo?) anche se non è stata utilizzata alcuna sessione invece di HttpSessionState quando viene chiamato SessionID.

È il motivo per cui string sessionId = Session.SessionID; Il trucco evita il problema.

Immagino che appaia solo all'avvio dell'applicazione a causa di comportamenti di inizializzazione.

Soluzioni/trucchi:

  • Evitare di vampate di calore in Page Load come già detto

  • Disattivare lo stato della sessione sulla pagina (EnableSessionState)

  • Usa il trucco SessionID prima che il filo

  • Utilizzare Response.End() in luogo di .Flush() se non si cura di errori che possono verificarsi dopo il vostro colore

0

riconosco questo è molto vecchio, ma ho trovato un altro motivo per l'errore che potrebbero applicarsi ad altri. Se si utilizza MVC (stavo usando MVC 4 con .Net 4.0) e di impostare le pagine per non tamponare utilizzando l'elemento web.config

<pages buffer="false">  

Poi, se nel codice si tenta di spingere i dati in oggetto di sessione, potrebbe essere il rischio di ottenere questo errore se la pagina ha avviato il rendering prima della visualizzazione figlio o dell'azione che esegue l'accesso allo stato della sessione.

In questi casi, è possibile correggere l'errore modificando l'impostazione del buffer sopra su true. In alternativa, sposta il codice di accesso della sessione nella vista principale e non in una azione figlio/vista figlio.

Problemi correlati