BUG: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.

Discussion in 'ASP .Net' started by Anthony Williams, Jun 8, 2004.

  1. Hi gang,

    This one looks like a bug :eek:(

    As you may or may not know, setting session management in web.config to use
    cookieless sessions causes the ASP.NET runtime to munge a session ID into
    the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
    which saves numerous headaches when it comes to storing state across page
    requests and sessions.

    It works very well for us - our website at www.listersgroup.co.uk uses
    cookieless sessions to good effect, with one minor drawback. It appears that
    whenever I use Response.Redirect(...) to move the client to a new page, the
    ASP.NET runtime wasn't built to handle it when cookieless sessions were
    being used.

    Example:
    Create a new Web Form in your chosen language. Set the web.config file to
    use cookieless sessions:

    <sessionState mode="InProc" cookieless="true" timeout="30" />

    Make a condition in your webform in the Subroutine which is called via
    Page.OnLoad:

    if (Request.QueryString("redirect") = "true") {
    Response.Redirect("thisWebForm.aspx");
    }

    or

    If Request.QueryString("redirect") = "true" Then
    Response.Redirect("thisWebForm.aspx")
    End If

    Watch as the session ID, which is munged into the URL, is magically ignored
    and a new one is chosen and re-munged in.

    This is causing loads of problems, and I'm looking to find a solution which
    will work regardless of location. If no-one else beats me to it, I'll post a
    workaround as soon as I'm done!

    Help?

    Kind regards,
    Anthony
     
    Anthony Williams, Jun 8, 2004
    #1
    1. Advertising

  2. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    "Anthony Williams" <> wrote in message
    news:O6zcd%...
    > Hi gang,
    >
    > This one looks like a bug :eek:(
    >
    > As you may or may not know, setting session management in web.config to

    use
    > cookieless sessions causes the ASP.NET runtime to munge a session ID into
    > the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
    > which saves numerous headaches when it comes to storing state across page
    > requests and sessions.
    >
    > It works very well for us - our website at www.listersgroup.co.uk uses
    > cookieless sessions to good effect, with one minor drawback. It appears

    that
    > whenever I use Response.Redirect(...) to move the client to a new page,

    the
    > ASP.NET runtime wasn't built to handle it when cookieless sessions were
    > being used.
    >
    > Example:
    > Create a new Web Form in your chosen language. Set the web.config file to
    > use cookieless sessions:
    >
    > <sessionState mode="InProc" cookieless="true" timeout="30" />
    >
    > Make a condition in your webform in the Subroutine which is called via
    > Page.OnLoad:
    >
    > if (Request.QueryString("redirect") = "true") {
    > Response.Redirect("thisWebForm.aspx");
    > }
    >
    > or
    >
    > If Request.QueryString("redirect") = "true" Then
    > Response.Redirect("thisWebForm.aspx")
    > End If
    >
    > Watch as the session ID, which is munged into the URL, is magically

    ignored
    > and a new one is chosen and re-munged in.
    >
    > This is causing loads of problems, and I'm looking to find a solution

    which
    > will work regardless of location. If no-one else beats me to it, I'll post

    a
    > workaround as soon as I'm done!


    Did you try to include the session id in the URL passed to
    Response.Redirect?
    --
    John Saunders
    johnwsaundersiii at hotmail
     
    John Saunders, Jun 8, 2004
    #2
    1. Advertising

  3. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    This might well be a bug, but I am not quite convinced. There are a couple
    of things to look at, as well as some architectural decisions.

    First, are you load balanced in any way? If so, you may have an issue here
    with the keys used to encrypt ViewState, et al. You have to manually set
    these in a farm, even one with the same state server.

    Second, have you messed with any state settings in either the page, the
    web.config or machine.config.

    Third, it is possible that bubble up of events affects this adversely.

    Architectural:
    The norm in ASP.NET is writing it like ASP, which is a horrible trend, IMO.
    This means we write a single function in a page, rather than treat a page
    like a class with multiple related functions. To rearchitect, you may end up
    with different panels that are available or hidden, and routes that ignore
    the hidden input, but it will get you around the munge issue with cookieless
    session state. If your developers do not have a background in windows
    programming, a few sample apps will get this concept down. Once you work
    with the methodology, you will find it is sound and gets you away from the
    issue you are having. You may be too late in the cycle to do this.

    If I get the chance, I will play with this a bit and see if I can figure out
    any ideas to aid you.

    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    ************************************************
    Think Outside the Box!
    ************************************************
    "Anthony Williams" <> wrote in message
    news:O6zcd%...
    > Hi gang,
    >
    > This one looks like a bug :eek:(
    >
    > As you may or may not know, setting session management in web.config to

    use
    > cookieless sessions causes the ASP.NET runtime to munge a session ID into
    > the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
    > which saves numerous headaches when it comes to storing state across page
    > requests and sessions.
    >
    > It works very well for us - our website at www.listersgroup.co.uk uses
    > cookieless sessions to good effect, with one minor drawback. It appears

    that
    > whenever I use Response.Redirect(...) to move the client to a new page,

    the
    > ASP.NET runtime wasn't built to handle it when cookieless sessions were
    > being used.
    >
    > Example:
    > Create a new Web Form in your chosen language. Set the web.config file to
    > use cookieless sessions:
    >
    > <sessionState mode="InProc" cookieless="true" timeout="30" />
    >
    > Make a condition in your webform in the Subroutine which is called via
    > Page.OnLoad:
    >
    > if (Request.QueryString("redirect") = "true") {
    > Response.Redirect("thisWebForm.aspx");
    > }
    >
    > or
    >
    > If Request.QueryString("redirect") = "true" Then
    > Response.Redirect("thisWebForm.aspx")
    > End If
    >
    > Watch as the session ID, which is munged into the URL, is magically

    ignored
    > and a new one is chosen and re-munged in.
    >
    > This is causing loads of problems, and I'm looking to find a solution

    which
    > will work regardless of location. If no-one else beats me to it, I'll post

    a
    > workaround as soon as I'm done!
    >
    > Help?
    >
    > Kind regards,
    > Anthony
    >
    >
     
    Cowboy \(Gregory A. Beamer\) [MVP], Jun 8, 2004
    #3
  4. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    "Cowboy (Gregory A. Beamer) [MVP]" <> wrote
    in message news:...
    > This might well be a bug, but I am not quite convinced. There are a couple
    > of things to look at, as well as some architectural decisions.
    >
    > First, are you load balanced in any way? If so, you may have an issue here
    > with the keys used to encrypt ViewState, et al. You have to manually set
    > these in a farm, even one with the same state server.


    Nope - I've actually disabled ViewState (originally I thought this may
    actually be the root cause of the problem) - and whilst we're not in a
    load-balanced situation (yet) we're already prepared for multiple servers -
    all of the keys in machine.config and web.config match on each server.

    > Second, have you messed with any state settings in either the page, the
    > web.config or machine.config.


    The only change I've made is to increase the session timeout from 20 to 30
    minutes:

    <sessionState mode="InProc" cookieless="true" timeout="30" />

    > Third, it is possible that bubble up of events affects this adversely.


    Again, I thought this might be a problem, but we've ruled this out too. All
    the events fire correctly, bubbling up as they should, and everything is
    handled as it should be - the problem occurs only when Response.Redirect is
    called with a relative URL.

    Also, it appears that - when using debug and the watch windows - that
    Request.Uri.AbsoluteUri.ToString completely ignores the inline munged
    SessionID. In fact, all the methods of Request.Uri ignore the fact that
    there is a SessionID in parenthesis in the requested URL. Perhaps this is a
    client/server communication problem, and not a problem in the ASP.NET
    runtime itself... I don't know.

    > Architectural:
    > The norm in ASP.NET is writing it like ASP, which is a horrible trend,
    > IMO.
    > This means we write a single function in a page, rather than treat a page
    > like a class with multiple related functions. To rearchitect, you may end
    > up
    > with different panels that are available or hidden, and routes that ignore
    > the hidden input, but it will get you around the munge issue with
    > cookieless
    > session state. If your developers do not have a background in windows
    > programming, a few sample apps will get this concept down. Once you work
    > with the methodology, you will find it is sound and gets you away from the
    > issue you are having. You may be too late in the cycle to do this.


    We've actually got our project and classes set up in a similar way to the
    IBS portal, whereby placeholders are used, and User Controls are added using
    Placeholder.Controls.Add(LoadControl("...")) in the order in the
    database/XML file we're using.

    > If I get the chance, I will play with this a bit and see if I can figure
    > out
    > any ideas to aid you.


    Cool, though for the record, I'm currently using this as a workaround, and
    it seems to work just fine:

    Public Shared Sub ResponseRedirect()
    HttpContext.Current.Response.Redirect(HttpContext.Current.Request.Url.AbsoluteUri.ToLower.Replace(HttpContext.Current.Request.ApplicationPath.ToLower,
    HttpContext.Current.Request.ApplicationPath.ToLower + "/(" +
    HttpContext.Current.Session.SessionID + ")"))
    End Sub
    Public Shared Sub ResponseRedirect(ByVal PathAndQuery As String)
    HttpContext.Current.Response.Redirect(HttpContext.Current.Request.Url.Scheme
    + HttpContext.Current.Request.Url.SchemeDelimiter +
    HttpContext.Current.Request.Url.Host +
    HttpContext.Current.Request.ApplicationPath + "/(" +
    HttpContext.Current.Session.SessionID + ")/" + PathAndQuery)
    End Sub


    Thanks for the help! If you do find anything out, I'd be very interested in
    seeing it!

    Regards,
    Anthony
     
    Anthony Williams, Jun 8, 2004
    #4
  5. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    John,

    When using relative URL fragments, it's not that easy to simply include the
    munged sessionID - I've posted a workaround, as a reply to Gregory's
    response, which shows how I'm getting around the problem, by using an
    absolute URL which is pieced together using various
    HttpContext.Current.Request objects and putting the SessionID in manually.

    Regards,
    Anthony

    "John Saunders" <> wrote in message
    news:...
    > "Anthony Williams" <> wrote in message
    > news:O6zcd%...
    >> Hi gang,
    >>
    >> This one looks like a bug :eek:(
    >>
    >> As you may or may not know, setting session management in web.config to

    > use
    >> cookieless sessions causes the ASP.NET runtime to munge a session ID into
    >> the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
    >> which saves numerous headaches when it comes to storing state across page
    >> requests and sessions.
    >>
    >> It works very well for us - our website at www.listersgroup.co.uk uses
    >> cookieless sessions to good effect, with one minor drawback. It appears

    > that
    >> whenever I use Response.Redirect(...) to move the client to a new page,

    > the
    >> ASP.NET runtime wasn't built to handle it when cookieless sessions were
    >> being used.
    >>
    >> Example:
    >> Create a new Web Form in your chosen language. Set the web.config file to
    >> use cookieless sessions:
    >>
    >> <sessionState mode="InProc" cookieless="true" timeout="30" />
    >>
    >> Make a condition in your webform in the Subroutine which is called via
    >> Page.OnLoad:
    >>
    >> if (Request.QueryString("redirect") = "true") {
    >> Response.Redirect("thisWebForm.aspx");
    >> }
    >>
    >> or
    >>
    >> If Request.QueryString("redirect") = "true" Then
    >> Response.Redirect("thisWebForm.aspx")
    >> End If
    >>
    >> Watch as the session ID, which is munged into the URL, is magically

    > ignored
    >> and a new one is chosen and re-munged in.
    >>
    >> This is causing loads of problems, and I'm looking to find a solution

    > which
    >> will work regardless of location. If no-one else beats me to it, I'll
    >> post

    > a
    >> workaround as soon as I'm done!

    >
    > Did you try to include the session id in the URL passed to
    > Response.Redirect?
    > --
    > John Saunders
    > johnwsaundersiii at hotmail
    >
    >
     
    Anthony Williams, Jun 8, 2004
    #5
  6. Anthony Williams

    Brad Guest

    Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    Anthony - Here's a stupid question. Does your app write anything to
    session? I don't know about cookiesless but my understanding of inproc
    session is that sessionid is not persisted until something adds to session
    i.e. a simple session.Add("myVar","Hello World") will cause sessionid to be
    persisted.

    Brad



    "Anthony Williams" <> wrote in message
    news:O6zcd%...
    > Hi gang,
    >
    > This one looks like a bug :eek:(
    >
    > As you may or may not know, setting session management in web.config to

    use
    > cookieless sessions causes the ASP.NET runtime to munge a session ID into
    > the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
    > which saves numerous headaches when it comes to storing state across page
    > requests and sessions.
    >
    > It works very well for us - our website at www.listersgroup.co.uk uses
    > cookieless sessions to good effect, with one minor drawback. It appears

    that
    > whenever I use Response.Redirect(...) to move the client to a new page,

    the
    > ASP.NET runtime wasn't built to handle it when cookieless sessions were
    > being used.
    >
    > Example:
    > Create a new Web Form in your chosen language. Set the web.config file to
    > use cookieless sessions:
    >
    > <sessionState mode="InProc" cookieless="true" timeout="30" />
    >
    > Make a condition in your webform in the Subroutine which is called via
    > Page.OnLoad:
    >
    > if (Request.QueryString("redirect") = "true") {
    > Response.Redirect("thisWebForm.aspx");
    > }
    >
    > or
    >
    > If Request.QueryString("redirect") = "true" Then
    > Response.Redirect("thisWebForm.aspx")
    > End If
    >
    > Watch as the session ID, which is munged into the URL, is magically

    ignored
    > and a new one is chosen and re-munged in.
    >
    > This is causing loads of problems, and I'm looking to find a solution

    which
    > will work regardless of location. If no-one else beats me to it, I'll post

    a
    > workaround as soon as I'm done!
    >
    > Help?
    >
    > Kind regards,
    > Anthony
    >
    >
     
    Brad, Jun 9, 2004
    #6
  7. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    Hi Anthony,

    Based on my test, I just create a two simple pages in my web project ,
    page1.aspx and page2.aspx. I set the session as inprocess and cookieless.
    And in page1.aspx, I use the following code in a button's click eventhandler

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
    System.EventArgs) Handles Button1.Click
    Response.Redirect("page2.aspx")

    End Sub

    and I've also tried Server.Transfer("page2.aspx"), they all works well
    without starting a new sessionid in url. But I did meet problems when
    change the url path as root based url such as

    Response.Redirect("/approot/page2.aspx") and also found the following
    article which also mentioned this behavior
    http://www.eggheadcafe.com/PrintSearchContent.asp?LINKID=401

    Hope helps.

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)

    Get Preview at ASP.NET whidbey
    http://msdn.microsoft.com/asp.net/whidbey/default.aspx
     
    Steven Cheng[MSFT], Jun 9, 2004
    #7
  8. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    "Anthony Williams" <> wrote in message
    news:%...

    > I'm currently using this as a workaround, and it seems to work just fine:
    >
    > Public Shared Sub ResponseRedirect()
    >
    > HttpContext.Current.Response.Redirect(HttpContext.Current.Request.Url.AbsoluteUri.ToLower.Replace(HttpContext.Current.Request.ApplicationPath.ToLower,
    > HttpContext.Current.Request.ApplicationPath.ToLower + "/(" +
    > HttpContext.Current.Session.SessionID + ")"))
    > End Sub
    > Public Shared Sub ResponseRedirect(ByVal PathAndQuery As String)
    >
    > HttpContext.Current.Response.Redirect(HttpContext.Current.Request.Url.Scheme
    > + HttpContext.Current.Request.Url.SchemeDelimiter +
    > HttpContext.Current.Request.Url.Host +
    > HttpContext.Current.Request.ApplicationPath + "/(" +
    > HttpContext.Current.Session.SessionID + ")/" + PathAndQuery)
    > End Sub
    >


    Anyone using the above may wish to try this newer, more reliable version
    out:

    Public Shared Sub Redirect()
    HttpContext.Current.Response.Redirect( _
    HttpContext.Current.Request.Url.AbsoluteUri.ToLower.Replace( _
    HttpContext.Current.Request.ApplicationPath.ToLower, _
    HttpContext.Current.Request.ApplicationPath.ToLower & _
    "/(" & HttpContext.Current.Session.SessionID & ")"))
    End Sub

    Public Shared Sub Redirect(ByVal PathAndQuery As String)
    Dim RedirectUrl As String
    If HttpContext.Current.Request.ApplicationPath = "/" Then
    RedirectUrl = HttpContext.Current.Request.Url.Scheme &
    HttpContext.Current.Request.Url.SchemeDelimiter &
    HttpContext.Current.Request.Url.Host & "/(" &
    HttpContext.Current.Session.SessionID & ")"
    Else
    RedirectUrl = HttpContext.Current.Request.Url.Scheme &
    HttpContext.Current.Request.Url.SchemeDelimiter &
    HttpContext.Current.Request.Url.Host &
    HttpContext.Current.Request.ApplicationPath & "/(" &
    HttpContext.Current.Session.SessionID & ")"
    End If

    RedirectUrl &= IIf(PathAndQuery.StartsWith("/"), "", "/") &
    PathAndQuery

    HttpContext.Current.Response.Redirect(RedirectUrl)
    End Sub
     
    Anthony Williams, Jun 9, 2004
    #8
  9. Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    "Brad" <> wrote in message
    news:...
    > Anthony - Here's a stupid question. Does your app write anything to
    > session? I don't know about cookiesless but my understanding of inproc
    > session is that sessionid is not persisted until something adds to session
    > i.e. a simple session.Add("myVar","Hello World") will cause sessionid to
    > be
    > persisted.


    AFAIK, Session.SessionID is persisted from the first request, though my
    Global class sets quite a few things on Session_Start.
     
    Anthony Williams, Jun 9, 2004
    #9
  10. Anthony Williams

    Brad Guest

    Re: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

    Hmmm. I tried your example and the cooklies id is remaining constant for
    me. Did a response redirect based on querystring param and response
    redirect based on postback of a link button and in both instances the munged
    id in the url remained constant. This was tested using framework 1.1
    (vs2003) on win2003 server.

    Brad

    "Anthony Williams" <> wrote in message
    news:...
    > "Brad" <> wrote in message
    > news:...
    > > Anthony - Here's a stupid question. Does your app write anything to
    > > session? I don't know about cookiesless but my understanding of inproc
    > > session is that sessionid is not persisted until something adds to

    session
    > > i.e. a simple session.Add("myVar","Hello World") will cause sessionid

    to
    > > be
    > > persisted.

    >
    > AFAIK, Session.SessionID is persisted from the first request, though my
    > Global class sets quite a few things on Session_Start.
    >
    >
     
    Brad, Jun 9, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    2,858
  2. Replies:
    2
    Views:
    3,292
    Ravi Singh (UCSD)
    May 10, 2006
  3. scottymo
    Replies:
    3
    Views:
    751
    Dominick Baier
    Sep 30, 2006
  4. Sal
    Replies:
    1
    Views:
    900
  5. Replies:
    4
    Views:
    330
    Bob Barrows [MVP]
    Sep 22, 2006
Loading...

Share This Page