Last post Sep 12, 2018 02:10 AM by DEVSupport_MSFT
Sep 03, 2018 08:34 AM|starlight54|LINK
So I recently wrote some code working off the application lifecycle events from the docs for IIS 7.0. https://msdn.microsoft.com/library/bb470252.aspx
This is clearly outdated now as can be seen by viewing the latest HttpApplication docs. https://docs.microsoft.com/en-us/dotnet/api/system.web.httpapplication?redirectedfrom=MSDN&view=netframework-4.7.2
So I was previously using the PostRequestHandlerExecute event which is guaranteed to fire before ReleaseRequestState
event (which I believe is the one that releases the Session object), however this
event is not guaranteed to fire before Headers have been sent.
Which is the best event to use when you want to do all of 1) Modify Headers and 2) Use some
Session data to do so 3) Ensure that the Headers set here are the final values sent to the client, at the moment PreSendRequestHeaders seems reasonable to me, but I can't find any guarantee that
Session will still be alive for the entire execution of this event?
It happens to be so during my testing, but this isn't a guarantee that it won't blow up one day :)
Sep 03, 2018 03:30 PM|bruce (sqlwork.com)|LINK
Sep 03, 2018 04:22 PM|starlight54|LINK
Thanks for the reply, I'll need to relax my constraints a little then.
Assuming that none of my code directly messes with the availability of the
Session, will it always be available during the PreSendRequestHeaders event?
The docs suggest this event can fire any time, but I'm hoping it's constrained to fire before
Session is released...
Sep 06, 2018 06:36 AM|Gary Liu - MSFT|LINK
Please refer to the following description:
Sessions are started during the first request and session values will persist as long as a new request is made by the browser before the number of minutes specified in the Timeout property
pass. When a new session begins, the session Start event is raised. You can use this event to perform
any additional work at the start of a session, such as setting default session values. When a session times out, the Abandon method
is called, or the ASP.NET application is shut down, the session End event is raised. You can use this
event to perform any necessary cleanup. The End event is raised only when the session state mode is
set to InProc.
So the seesion will not be released in ReleaseRequestState event. Instead, this event is used by the session state module to update the dirty session state if necessary. You can find the description at http://www.nicologies.tk/posts/ASPNETEventPipeline.
You can refer to https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate?view=netframework-4.7.2
for more details about session state.
Sep 06, 2018 09:16 AM|starlight54|LINK
Aye Release is perhaps a bad word, I'm talking about the object rather than the entire User Session, essentially, if you attempt to access
HttpContext.Current.Session during events after ReleaseRequestState it will be equivalent to
null, and you will not be able to access it.
I want to know if it's guaranteed to not be null during the PreSendRequestHeaders
event, since this event is not guaranteed to execute at any given time, it seems like it's
async, therefore it may fire before or after the HttpContext.Current.Session is set to
null during the pipeline, but I need to not be null in this case for my purposes.
Sep 07, 2018 08:18 AM|starlight54|LINK
Ah I have discovered a time when Session is indeed nuked prior to the PreSendRequestHeaders event, the only solution I've got thus far is to save the items from
Session into Context.Items during the PostAcquireRequestState event and then I can access them at any time even if the
Session is nuked...
Sep 12, 2018 02:10 AM|DEVSupport_MSFT|LINK
for the questions mentioned above, please refer below:
As the document of
https://forums.asp.net/t/2146386.aspx clarified, The application events are raised in the following order, and the header was send in PreSendRequestHeaders event, which occurred occurs just before ASP.NET sends HTTP headers to the client. Of course, it
should occurred after the 19. EndRequest event.
Session was released in the event of ReleaseRequestState, so we can’t get the content of HttpContext.Current.Session and it was set to null