Що спричиняє "Стан сеансу створив ідентифікатор сеансу, але не може його зберегти, оскільки відповідь уже змита додатком."

Я отримую цю несправність з перервами.

Я знайшов це посилання, яке досить добре узагальнює те, що мені вдалося знайти в Google: http://www.wacdesigns.com/2009/02/03/session-state-has-created-a-session-id-but- не вдається зберегти його, бо відповідь вже була змита додатком /

В основному там сказано, що ви можете спробувати встановити налаштування веб-конфігурації DisplayWhenNewSession, або спробувати ввести в дію стан сеансу, отримавши Session.SessionID у Session_OnStart.

Але хтось:

а) мати пояснення цьому

або ще краще, б) мати випробуване виправлення

Я усвідомлюю, що не можу змити відповідь, зробивши щось, що може вплинути на заголовок відповіді http. Якби я це зробив, це би спричиняло помилку кожного разу, але це періодично. Ідентифікатор Session, безперечно, повинен бути створений ASP.NET на початку відповіді сторінки автоматично, перед будь-чим на сторінці ASPX або Page_Load (саме там називаються всі мої флеші).

Оновлення: Після роздумів я розумію, що це відбувається під час потокового передавання файлу до браузера. Більшість браузерів насправді є ботами пошукових систем. Я можу відтворити цю помилку, запустивши завантаження, а потім закривши браузер, тому, мабуть, браузери не чекають завершення завантаження, перш ніж скасувати операцію завантаження. Я також бачив це на інших звичайних сторінках, але 99% часу це сторінки завантаження.

Я маю!

У файлі global.asax ви робите це:

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

Так легко. Це працює!

Здається, ця помилка з’являється, коли:

• Запуск програми

• Ви використовуєте Global.asax, навіть якщо ви щось робите в подіях Session_Start / End чи ні

• Ваша програма примушує змити відповідь занадто рано

• Ви не використовуєте сеанс перед флешем

Це підвищується станом сесії при спробі зберегти сеанс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 призводить до збереження ідентифікатора сесії при випуску SessionStateModule (пізно?), Навіть якщо жоден сеанс не використовувався замість HttpSessionState при виклику SessionID.

Це причина, чому рядок sessionId = Session.SessionID; трюк уникнути проблеми.

Думаю, це з’являється лише під час запуску програми через поведінку ініціалізації.

Рішення / хитрощі :

• Уникайте змивів у Page_Load, як уже було сказано

• Дезактивувати стан сеансу на сторінці (EnableSessionState)

• Використовуйте трюк SessionID перед флешем

• Використовуйте Response.End () замість .Flush (), якщо вам байдужі помилки, які можуть виникнути після вашого змиву

Я вважаю, що проблема тут може бути саме в тому, що ви щось робите, щоб викликати вихід сторінки під час Page_Load, що, згідно з оглядом життєвого циклу сторінки ASP.NET , задовго до етапу візуалізації.

Переконайтеся, що ви ніколи не робите нічого, що може спричинити виведення сторінки, лише після закінчення PreRenderетапу.

Щойно зіткнувшись із цією проблемою, я подумав поділитися своїми висновками.

Налаштування web.config DisplayWhenNewSession не має значення, оскільки воно стосується лише одного конкретного користувацького контролю в Codeplex (вибачте, що я втратив посилання).

Інша пропозиція, здається, спрацьовує шляхом ранньої ініціалізації SessionId. Я копався в коді за допомогою Reflector і не міг зрозуміти, як це запобігло помилці тут, але це, безумовно, спрацювало для нас!

Як і більшість людей, які, здається, стикаються з цією помилкою, ми явно не викликаємо Response.Flush () ніде в додатку. Для запису ми також використовуємо MVC.

Я усвідомлюю, що це дуже давно, але я знайшов ще одну причину помилки, яка може стосуватися інших. Якщо ви використовуєте MVC (я використовував MVC 4 з .Net 4.0), і ви встановлюєте, щоб сторінки не буферизувались за допомогою елемента web.config

<pages buffer="false">    

Тоді, якщо у коді ви намагаєтесь всунути дані в об’єкт сеансу, можливо, ви ризикуєте отримати цю помилку, якщо сторінка розпочала рендерінг до того, як ваш дочірній перегляд або дія, що виконує доступ до стану сеансу.

У таких випадках ви можете виправити помилку, змінивши налаштування буфера вище на true. Або ж перемістіть код доступу до сеансу в основне представлення, а не в дочірню дію / дочірній вигляд.