Is Session guranteed to still be available during the PreSendRequestHeaders event? RRS feed

  • Question

  • User-114310237 posted

    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 :)

    Monday, September 3, 2018 8:34 AM


All replies

  • User-474980206 posted
    There is no completely safe event. The action can change headers and thus override pre request, or it can flush the headers and prevent post request from modifying the headers. Also if the controller disable session there is no session loaded.

    This is all improved in asp.net core.
    Monday, September 3, 2018 3:30 PM
  • User-114310237 posted

    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...

    Monday, September 3, 2018 4:22 PM
  • User1163516801 posted

    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.

    <audio controls="controls" style="display: none;"></audio>

    Thursday, September 6, 2018 6:36 AM
  • User-114310237 posted

    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.

    Thursday, September 6, 2018 9:16 AM
  • User-114310237 posted

    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...

    Friday, September 7, 2018 8:18 AM
  • User-1492487179 posted

    for the questions mentioned above, please refer below:

    1. RequestHandlerExecute is not guaranteed to fire before Headers have been sent


    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.

    1. BeginRequest
    2. AuthenticateRequest
    3. PostAuthenticateRequest
    4. AuthorizeRequest
    5. PostAuthorizeRequest
    6. ResolveRequestCache
    7. PostResolveRequestCache
    8. PostMapRequestHandler
    9. AcquireRequestState
    10. PostAcquireRequestState
    11. PreRequestHandlerExecute
    12. PostRequestHandlerExecute
    13. ReleaseRequestState
    14. PostReleaseRequestState
    15. UpdateRequestCache
    16. PostUpdateRequestCache
    17. LogRequest.
    18. PostLogRequest
    19. EndRequest


    1. Can't find any guarantee that Sessionwill still be alive for the entire execution of this 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

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 12, 2018 2:10 AM