Qu'est-ce qui cause "L'état de session a créé un ID de session, mais ne peut pas le sauvegarder car la réponse a déjà été vidée par l'application."

Question

Je reçois cette erreur par intermittence.

J'ai trouvé ce lien qui résume assez bien ce que j'ai pu trouver sur 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/

Fondamentalement, il dit que vous pouvez essayer de régler la configuration web réglage DisplayWhenNewSession, ou essayer coups de pied la chose d'état de session dans la vie en obtenant le Session.SessionID dans le Session_OnStart.

Mais quelqu'un:

a) ont une explication pour cette

ou mieux encore, b) ont un essayé et testé fixer

Je me rends compte que je ne peux pas vider la réponse après faire quoi que ce soit qui affecterait l'en-tête de la réponse http. Si je l'ai fait cela provoquerait une erreur chaque fois mais c'est intermittent. Le SessionID devrait sûrement être créé par ASP.NET au début de la réponse de page automatiquement, avant n'importe quoi dans la page ASPX ou le Page_Load (qui est où tous mes flushes sont appelés).

Mise à jour: À la réflexion, je me rends compte que cela se produit lors de la diffusion d'un fichier vers le navigateur. La plupart des navigateurs sont en fait des robots de recherche. Je peux recréer cette erreur en démarrant un téléchargement puis en fermant le navigateur, donc les navigateurs n'attendent probablement pas que le téléchargement se termine avant d'annuler l'opération de téléchargement. J'ai aussi vu cela sur d'autres pages normales, mais 99% du temps c'est des pages de téléchargement.

Answer 1

Je l'ai!

Dans le fichier global.asax vous faites ceci:

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

si facile. Ça marche!

Answer 2

Je crois que le problème ici peut être exactement que vous faites quelque chose pour provoquer la sortie de la page pendant Page_Load, qui, selon le ASP.NET Page Lifecycle Overview est longtemps avant l'étape de rendu.

Assurez-vous de ne jamais faire quoi que ce soit qui pourrait déclencher la sortie de la page qu'après l'étape PreRender.

Answer 3

Après avoir moi-même rencontré ce problème, j'ai pensé partager mes conclusions.

Le paramètre web.config DisplayWhenNewSession n'est pas pertinent car il ne s'applique qu'à un contrôle personnalisé particulier sur Codeplex (désolé j'ai perdu le lien).

L'autre suggestion semble fonctionner en initialisant le SessionId au début. J'ai creusé dans le code en utilisant Reflector et je n'arrivais pas à voir comment cela pouvait empêcher l'erreur ici, mais ça a certainement marché pour nous!

Comme la plupart des gens qui semblent rencontrer ce bogue, nous n'appelons pas explicitement Response.Flush() n'importe où dans l'application. Nous utilisons également MVC, pour le compte rendu.

Answer 4

Cette erreur semble apparaître lorsque:

• L'application commencer

• Vous utilisez un Global.asax même si vous faites quelque chose dans les événements Session_Start/fin ou non

• Votre application force la chasse de la réponse trop tôt

• Vous n'êtes pas en utilisant la Sessio n avant la chasse

Il est élevé par l'état de session quand il essaie de sauver le idSession sur la libération:

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) 

Je crois que la présence de Global.asax provoque l'ID de session pour être sauvé à la sortie par le SessionStateModule (late?) même si aucune session n'a été utilisée à la place de HttpSessionState lors de l'appel de SessionID.

C'est la raison pour laquelle string sessionId = Session.SessionID; truc éviter le problème.

Je suppose qu'il apparaît uniquement au démarrage de l'application en raison des comportements d'initialisation.

Solutions/astuces:

• Évitez de rinçage dans Page_Load comme déjà dit

• état de session Désactiver sur la page (EnableSessionState)

• Utilisez le truc SessionID avant la chasse

• Utiliser Response.End() dans lieu de .Flush() si vous ne se soucient pas des erreurs qui peuvent se produire après votre chasse d'eau

Answer 5

Je reconnais ce qui est très vieux, mais j'ai trouvé une autre raison de l'erreur qui pourrait appliquer à d'autres. Si vous utilisez MVC (j'utilisais MVC 4 avec .Net 4.0) et définissez les pages à ne pas tamponner en utilisant l'élément web.config

<pages buffer="false">  

Ensuite, si dans votre code que vous essayez de pousser des données dans le objet session, risque d'obtenir cette erreur si la page a commencé à être rendue avant la vue enfant ou l'action exécutant l'accès à l'état de la session.

Dans ce cas, vous pouvez corriger l'erreur en définissant le paramètre de tampon ci-dessus sur true. Vous pouvez également déplacer votre code d'accès de session vers la vue principale et non vers une vue enfant/enfant.