Infinite loop when using Server.Transfer

[Alexander Bosch]

Hi,
I'm having a problem similar to the one that's stated in this KB
http://support.microsoft.com/default...b;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

[Steven Cheng[MSFT]]

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

[Alexander Bosch]

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/ad******.../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.)

[Steven Cheng[MSFT]]

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]

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]" <v-******@online.microsoft.com> wrote in message
news:O0**************@cpmsftngxa10.phx.gbl...

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

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

[Alexander Bosch]

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

[Steven Cheng[MSFT]]

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

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]

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]" <v-******@online.microsoft.com> wrote in message
news:lq**************@cpmsftngxa10.phx.gbl...

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

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

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