Infinite loop when using Server.Transfer

Discussion in 'ASP .Net' started by Alexander Bosch, Oct 28, 2004.

  1. Hi,
    I'm having a problem similar to the one that's stated in this KB
    http://support.microsoft.com/default.aspx?scid=kb;en-us;839521
    When I'm posting a page to itself with the bool value as true it falls into
    an infinite loop and later a StackOverflow Exception. I need to do this and
    not a Response.Redirect or a transfer with the bool in false.
    My problem is that this KB is saying that this problem should be solved with
    ServicePack 1 of .NET 1.1. I've installed this and that's the only version
    of .NET on my PC, but I keep getting the same error.
    Any help would be appreciated.
    Thanks
    Alexander
     
    Alexander Bosch, Oct 28, 2004
    #1
    1. Advertising

  2. Hi Alexander,

    Thanks for your posting. As for the problem you mentioned, I've checked the
    kb article, seems the kb article haven't explained the cause detailedly.
    Also, I'm feel strange that the kb said the problem may resolved after the
    installed the latest .net 1.1 sp , but you're still suffering it after that
    ,yes?

    Anyway, I'll explain the root cause of the problem first:
    =====================================
    Cause: This is due to a change in behavior of the Server.Transfer method.
    From .NET
    version 1.0 to 1.1 the Server.Transfer behaves differently. In version 1.0,
    Server.Transfer preserves the Forms collection and the QueryString
    property, and
    considers the Transfer method as part of a postback. Therefore, the
    Page.IsPostBack
    property is set to true. Initially version 1.1, the transfer is not
    considered part
    of the postback and Page.IsPostBack is set to false even if Server.Transfer
    transfers back to itself. With the fix from 821758, the functionality from
    v1.0 was
    added to v1.1 - that is, the IsPostBack is set to true and the forms
    collection is
    preserved by default. If a page transfers to itself it will be considered a
    postback, however, with such a postback the page object is retained so when
    the
    postback occurs the event that trigger the server.transfer will be fired
    again. If
    this postback event is not trapped in the event the Server.Transfer method
    will be
    executed again. On all subsequent transfers the same process will occur
    cauing the
    page to transfer to itself repeatedly until all stack space is used and the
    Stack
    Overflow exception is genrated.
    ===========================================

    Also, here are some available resolutions against the cause of the problem:

    Using the false attribute with Server.Transfer will resolve the issue, for
    example:

    Server.Transfer('selfpage.aspx',false);

    however, this'll make on a transfer to itself the page will no longer have
    access to the Forms
    collection. If maintaining the Forms collection is required as part of the
    "postback", some additional code should be added to the event triggering
    the Server.Transfer
    call to check for an IsPostBack or other session variable indicating that
    the
    transfer has taken place and should not execute again. For example, either
    of the
    following code would keep the Server.Transfer from executing on subsequent
    postbacks:
    Option One: Check for postback
    If (!IsPostBack)
    {
    Server.Transfer("webform1.aspx", true)
    {
    Option Two: Set a page item to use as a flag
    if (Context.Items["Transfered"] == null)
    {
    Context.Items["Transfered"] = new object();
    Server.Transfer("foo.aspx", true);
    }


    Hope these helps. Also, if you have anything unclear, please feel free to
    post here. Thanks.

    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.)
     
    Steven Cheng[MSFT], Oct 29, 2004
    #2
    1. Advertising

  3. Hi Steve, thanks for your reply.
    I've got to use the Server.TRansfer with the variable set to true as I need
    the Forms Collection.
    Checking for (IsPostBack) does not work as (as the KB article says) the
    PostBack does not get finalized, so the PostBack value is always true, right?
    I've found this
    http://www.mail-archive.com//msg06214.html
    discussion regarding the same problem after Service Pack 1...Can you find out
    more about this issue as it looks like it's not just me?

    thanks!
    Alexander


    "Steven Cheng[MSFT]" wrote:

    > Hi Alexander,
    >
    > Thanks for your posting. As for the problem you mentioned, I've checked the
    > kb article, seems the kb article haven't explained the cause detailedly.
    > Also, I'm feel strange that the kb said the problem may resolved after the
    > installed the latest .net 1.1 sp , but you're still suffering it after that
    > ,yes?
    >
    > Anyway, I'll explain the root cause of the problem first:
    > =====================================
    > Cause: This is due to a change in behavior of the Server.Transfer method.
    > From .NET
    > version 1.0 to 1.1 the Server.Transfer behaves differently. In version 1.0,
    > Server.Transfer preserves the Forms collection and the QueryString
    > property, and
    > considers the Transfer method as part of a postback. Therefore, the
    > Page.IsPostBack
    > property is set to true. Initially version 1.1, the transfer is not
    > considered part
    > of the postback and Page.IsPostBack is set to false even if Server.Transfer
    > transfers back to itself. With the fix from 821758, the functionality from
    > v1.0 was
    > added to v1.1 - that is, the IsPostBack is set to true and the forms
    > collection is
    > preserved by default. If a page transfers to itself it will be considered a
    > postback, however, with such a postback the page object is retained so when
    > the
    > postback occurs the event that trigger the server.transfer will be fired
    > again. If
    > this postback event is not trapped in the event the Server.Transfer method
    > will be
    > executed again. On all subsequent transfers the same process will occur
    > cauing the
    > page to transfer to itself repeatedly until all stack space is used and the
    > Stack
    > Overflow exception is genrated.
    > ===========================================
    >
    > Also, here are some available resolutions against the cause of the problem:
    >
    > Using the false attribute with Server.Transfer will resolve the issue, for
    > example:
    >
    > Server.Transfer('selfpage.aspx',false);
    >
    > however, this'll make on a transfer to itself the page will no longer have
    > access to the Forms
    > collection. If maintaining the Forms collection is required as part of the
    > "postback", some additional code should be added to the event triggering
    > the Server.Transfer
    > call to check for an IsPostBack or other session variable indicating that
    > the
    > transfer has taken place and should not execute again. For example, either
    > of the
    > following code would keep the Server.Transfer from executing on subsequent
    > postbacks:
    > Option One: Check for postback
    > If (!IsPostBack)
    > {
    > Server.Transfer("webform1.aspx", true)
    > {
    > Option Two: Set a page item to use as a flag
    > if (Context.Items["Transfered"] == null)
    > {
    > Context.Items["Transfered"] = new object();
    > Server.Transfer("foo.aspx", true);
    > }
    >
    >
    > Hope these helps. Also, if you have anything unclear, please feel free to
    > post here. Thanks.
    >
    > 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.)
    >
    >
    >
    >
    >
     
    =?Utf-8?B?QWxleGFuZGVyIEJvc2No?=, Oct 29, 2004
    #3
  4. Hi Alexander,

    Thanks for your followup. After some further checks in the product's known
    issue list. It seems that this is still a existing issue of asp.net when we
    calling server.transfer with the second parameter as "true". The kb article
    you mentioned

    http://support.microsoft.com/?id=839521

    do address on this problem. However, the resolution in .net1.1 sp1 it
    mentioned means the after sp1.1 the Server.Transfer will have the following
    new behavior:
    ===============================
    Server.Transfer Call Results
    Server.Transfer(different page, false) Query string data is dropped, and
    form data collection is dropped.
    Server.Transfer(different page) Query string data is dropped, and form
    data collection is preserved.
    Server.Transfer(different page, true) Query string data is preserved, and
    form data collection is preserved.
    Server.Transfer(same page, false) Query string data is dropped, and form
    data collection is dropped.
    Server.Transfer(same page) Query string data is dropped, and form data
    collection is preserved.
    Server.Transfer(same page, true) Query string data is preserved, and form
    data collection is preserved.
    =================================

    And based on the cause of this problem( I mentioned in the last reply), it
    will still cause stackoverflow if we calling sever.transfer with second
    parameter as "true" in postback event.

    Currently I think you can try the following workaround:
    ===========================
    Option Two: Set a page item to use as a flag
    if (Context.Items["Transfered"] == null)
    {
    Context.Items["Transfered"] = new object();
    Server.Transfer("foo.aspx", true);
    }
    ==============================

    It add a flag item in the request's context collection and will prevent
    infinite loop.

    Please have a try and let me know if it helps. Also, since this is a known
    issue , I'm sorry for any inconvenience it has bring you.

    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.)
     
    Steven Cheng[MSFT], Nov 1, 2004
    #4
  5. Hi Steve,
    thanks for replying...any ideas if this issue it's going to be adressed by
    Microsoft in the near future?
    My problem is a litle more complicated than just checking for a variable on
    the Page context as we are using the User Interface Process, and, instead of
    Response.Redirect every page we are doing a Server.Transfer to keep the
    forms collection.
    I'll see if I can do a little trick tomorrow based on your idea...but I
    would appreciate if you can find out, or at least point me in the right
    direction if this is a case that should be opened with Microsoft to find a
    long term solution.
    thanks Again,
    Alexander


    "Steven Cheng[MSFT]" <> wrote in message
    news:...
    > Hi Alexander,
    >
    > Thanks for your followup. After some further checks in the product's known
    > issue list. It seems that this is still a existing issue of asp.net when

    we
    > calling server.transfer with the second parameter as "true". The kb

    article
    > you mentioned
    >
    > http://support.microsoft.com/?id=839521
    >
    > do address on this problem. However, the resolution in .net1.1 sp1 it
    > mentioned means the after sp1.1 the Server.Transfer will have the

    following
    > new behavior:
    > ===============================
    > Server.Transfer Call Results
    > Server.Transfer(different page, false) Query string data is dropped, and
    > form data collection is dropped.
    > Server.Transfer(different page) Query string data is dropped, and form
    > data collection is preserved.
    > Server.Transfer(different page, true) Query string data is preserved, and
    > form data collection is preserved.
    > Server.Transfer(same page, false) Query string data is dropped, and form
    > data collection is dropped.
    > Server.Transfer(same page) Query string data is dropped, and form data
    > collection is preserved.
    > Server.Transfer(same page, true) Query string data is preserved, and form
    > data collection is preserved.
    > =================================
    >
    > And based on the cause of this problem( I mentioned in the last reply), it
    > will still cause stackoverflow if we calling sever.transfer with second
    > parameter as "true" in postback event.
    >
    > Currently I think you can try the following workaround:
    > ===========================
    > Option Two: Set a page item to use as a flag
    > if (Context.Items["Transfered"] == null)
    > {
    > Context.Items["Transfered"] = new object();
    > Server.Transfer("foo.aspx", true);
    > }
    > ==============================
    >
    > It add a flag item in the request's context collection and will prevent
    > infinite loop.
    >
    > Please have a try and let me know if it helps. Also, since this is a known
    > issue , I'm sorry for any inconvenience it has bring you.
    >
    > 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.)
    >
    >
     
    Alexander Bosch, Nov 1, 2004
    #5
  6. Hi Alexander,

    Thanks for your followup. Currently I also have no idea whether the
    problem will soon be fixed. But I can try consulting some further experts
    on this to see whether there is any plan on this in the near furture.
    Also, since you mentioned that you'll try finding some trick based on the
    workaround, please feel free to let me know if you meet any problems on
    workaround it so that I can also involve this when consulting.
    (You can provide some detailed info of how your WEB UI systems works and
    what's troubles you meet when using the workaround so that I can ask for
    some detailed suggestions or whether we need an additional hotfix on this).

    Looking forward to your good news.

    Thanks.

    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.)
     
    Steven Cheng[MSFT], Nov 1, 2004
    #6
  7. Hi Steve,
    I used your idea and it looks like it's working.
    As we've said this is a workaround and we don't want to promote this code
    until we get an estimate value regarding how long would it take fro Microsoft
    to solve this issue.
    We are thinking of opening a ticket with Microsoft to deal with this issue.
    Can you point me in the right direction? Do you have any other idea?
    thanks,
    Alexander

    "Steven Cheng[MSFT]" wrote:

    > Hi Alexander,
    >
    > Thanks for your followup. Currently I also have no idea whether the
    > problem will soon be fixed. But I can try consulting some further experts
    > on this to see whether there is any plan on this in the near furture.
    > Also, since you mentioned that you'll try finding some trick based on the
    > workaround, please feel free to let me know if you meet any problems on
    > workaround it so that I can also involve this when consulting.
    > (You can provide some detailed info of how your WEB UI systems works and
    > what's troubles you meet when using the workaround so that I can ask for
    > some detailed suggestions or whether we need an additional hotfix on this).
    >
    > Looking forward to your good news.
    >
    > Thanks.
    >
    > 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.)
    >
    >
     
    =?Utf-8?B?QWxleGFuZGVyIEJvc2No?=, Nov 1, 2004
    #7
  8. Hi Alexander,

    Thanks for your followup. If don't feel very urgent, I'll first consult the
    dev team or some other experts to see whether the problem will be addressed
    in the near feature. IF still no result , I think maybe you need to open a
    ticket to work on this specific issue. I'll update you as soon as possible.
    Thanks.


    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.)
     
    Steven Cheng[MSFT], Nov 2, 2004
    #8
  9. Hi Alexander,

    Just add a note to tell you that we're stilling focus on this issue and
    requesting for some further information from the dev team and will update
    as soon as possible. Thanks for your understanding.

    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.)
     
    Steven Cheng[MSFT], Nov 5, 2004
    #9
  10. Hi Steve,
    I Appreciate your help.
    We are kind of running out of time though...DO you think opening a ticket
    would speed up the process?
    Thanks Again,
    Alexander
    "Steven Cheng[MSFT]" <> wrote in message
    news:lqXz$...
    > Hi Alexander,
    >
    > Just add a note to tell you that we're stilling focus on this issue and
    > requesting for some further information from the dev team and will update
    > as soon as possible. Thanks for your understanding.
    >
    > 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.)
    >
     
    Alexander Bosch, Nov 5, 2004
    #10
  11. Hi Alexander,

    Thanks for your followup. Well, there seems no more info I can provide on
    this issue. But if you do feel it necessary to get a definite answer or a
    better workaround on this issue, you can try contacting the PSS to open a
    regular case to work on this problem.Thanks.

    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.)
     
    Steven Cheng[MSFT], Nov 8, 2004
    #11
  12. Hi Alexander,

    Have you got any further progress or have opened a ticket to work on it ?
    Anyway, if there're anything else we can help, please feel free to let us
    know. Thanks.


    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.)
     
    Steven Cheng[MSFT], Nov 10, 2004
    #12
    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. Alexander Bosch

    Infinite loop when using Server.Transfer

    Alexander Bosch, Oct 31, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    559
    Steven Cheng[MSFT]
    Nov 1, 2004
  2. Replies:
    5
    Views:
    620
    benben
    Jan 31, 2006
  3. Hukkky

    Server/Client infinite loop problem

    Hukkky, Oct 24, 2008, in forum: C Programming
    Replies:
    3
    Views:
    434
    Keith Thompson
    Oct 25, 2008
  4. Jim
    Replies:
    1
    Views:
    965
    Aaron Bertrand - MVP
    Jan 28, 2004
  5. Isaac Won
    Replies:
    9
    Views:
    419
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page