it-roy-ru.com

Что вызывает "Состояние сеанса создало идентификатор сеанса, но не может сохранить его, потому что ответ уже был сброшен приложением".

Я периодически получаю эту ошибку. 

Я нашел эту ссылку, которая довольно хорошо суммирует то, что я смог найти в Google: http://www.wacdesigns.com/2009/02/03/session-state-has-created-a-session -Id-но-не-сохранить-это-потому-что-ответ уже был сброшен приложением/

По сути, это говорит о том, что вы можете попытаться установить параметр веб-конфигурации DisplayWhenNewSession или попытаться запустить состояние сеанса, получив Session.SessionID в Session_OnStart.

Но разве кто-нибудь:

а) есть объяснение этому

или даже лучше, б) иметь проверенное и исправленное

Я понимаю, что не могу сбросить ответ после того, как что-то повлияет на заголовок http-ответа. Если бы я сделал это, это вызвало бы ошибку каждый раз, но это периодически. SessionID, безусловно, должен автоматически создаваться ASP.NET в начале ответа страницы, прежде чем что-либо на странице ASPX или в Page_Load (именно там вызываются все мои сбрасывания).

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

68
mike nelson

Я имею!

В файле global.asax вы делаете это:

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

Так просто. Оно работает!

74
eitama

Эта ошибка появляется, когда:

  • Запуск приложения

  • Вы используете Global.asax, даже если вы что-то делаете в событиях Session_Start/End или нет

  • Ваше приложение вызывает сброс ответа слишком рано

  • Вы не используете сессию до сброса

Это вызвано состоянием сеанса, когда это пытается сохранить 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 приводит к тому, что идентификатор сессии сохраняется при выпуске с помощью SessionStateModule (поздно?), Даже если сессия не использовалась вместо HttpSessionState при вызове SessionID.

Это причина, почему строка sessionId = Session.SessionID; хитрость избежать проблемы.

Я предполагаю, что это появляется только при запуске приложения из-за поведения инициализации.

Решения/фокусы :

  • Избегайте смыва в Page_Load, как уже говорилось

  • Деактивировать состояние сеанса на странице (EnableSessionState)

  • Используйте трюк SessionID перед сбросом

  • Используйте Response.End () вместо .Flush (), если вас не волнуют ошибки, которые могут возникнуть после сброса

19
JoeBilly

Я полагаю, что проблема здесь может заключаться именно в том, что вы что-то делаете для вывода страницы во время Page_Load, что, согласно ASP.NET Page Life Overview Overview , задолго до стадии рендеринга.

Убедитесь, что вы никогда не делаете ничего, что могло бы вызвать вывод страницы, пока не пройдете этап PreRender.

6
Curt J. Sampson

Просто столкнувшись с этой проблемой, я решил поделиться своими выводами.

Параметр web.config DisplayWhenNewSession не имеет значения, поскольку он применяется только к одному конкретному пользовательскому элементу управления в Codeplex (извините, я потерял ссылку).

Другое предложение, кажется, работает, инициализируя SessionId рано. Я копался в коде с помощью Reflector и не мог понять, как это предотвратило ошибку, но это, безусловно, сработало для нас!

Как и большинство людей, которые, похоже, сталкиваются с этой ошибкой, мы нигде не вызываем Response.Flush () в приложении. Мы также используем MVC, для записи.

3
Gaz

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

<pages buffer="false">    

Затем, если в вашем коде вы пытаетесь вставить данные в объект сеанса, возможно, вы рискуете получить эту ошибку, если страница начала отображаться до вашего дочернего представления или действия, выполняющего доступ к состоянию сеанса.

В таких случаях вы можете исправить ошибку, изменив настройки буфера выше на true. Также можно переместить код доступа к сеансу в главное представление, а не в дочернее действие/дочернее представление.

0
Mike Teye