使用Server.Transfer时无限循环 [英] Infinite loop when using Server.Transfer

问题描述

我遇到类似于这个KB中所述的问题
http://support.microsoft.com/default...b;en-us;839521

当我将bool值发布为自己的页面为true时，它会落入

无限循环以及之后的StackOverflow异常。我需要这样做并且

不是Response.Redirect或bool的传输错误。

我的问题是这个KB说这个问题应该解决使用

.NET 1.1的ServicePack 1。我已经安装了这个，这是我PC上唯一的.NET版本，但我一直都会遇到同样的错误。

任何帮助都将不胜感激。

谢谢

亚历山大

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

推荐答案

嗨亚历山大，

感谢您的发布。至于你提到的问题，我已经检查了

kb文章，似乎kb文章没有详细解释原因。
另外，我''我觉得奇怪的是，kb说这个问题可能在

安装了最新的.net 1.1 sp之后解决了，但是你之后还在苦苦挣扎

，是吗？


无论如何，我先解释问题的根本原因：

=============== ======================

原因：这是由于Server.Transfer方法的行为发生了变化。

从.NET

版本1.0到1.1 Server.Transfer的行为有所不同。在1.0版本中，

Server.Transfer保留Forms集合和QueryString

属性，

将Transfer方法视为回发的一部分。因此，

Page.IsPostBack

属性设置为true。最初版本1.1，转移不是

被视为部分

的回发和Page.IsPostBack设置为false，即使Server.Transfer

转回自己。通过821758的修复，

v1.0的功能是

添加到v1.1 - 也就是说，IsPostBack设置为true并且表单

集合默认保留为
。如果一个页面转移到它自己，它将被视为一个

回发，但是，这样的回发页面对象被保留，所以当



回发发生触发server.transfer的事件将再次被触发

。如果

这个回发事件没有被困在事件中，Server.Transfer方法

将再次执行
。在所有后续传输中，将发生相同的过程

警告

页面反复传输到自身，直到使用所有堆栈空间和

堆栈

溢出异常是生成的。

============================= ==============


此外，这里有一些针对问题原因的可用解决方案：


使用带有Server.Transfer的false属性将解决问题，例如：


Server.Transfer（''selfpage.aspx''，假的;


然而，这将'转移到自己页面将不再有

访问表格

集合。如果需要维护Forms集合作为

" postback"的一部分，则应该在触发事件时添加一些额外的代码

Server.Transfer

调用以检查IsPostBack或其他会话变量，表明已经发生了

转移并且不应该再次执行。例如，

以下代码中的
将阻止Server.Transfer在后续的

回发中执行：

选项一：检查回发

如果（！IsPostBack）

{

Server.Transfer（" webform1.aspx"，true） ）

{

选项二：设置一个用作标志的页面项目

if（Context.Items [" Transfered"] = = null）

{

Context.Items [" Transfered"] = new object（）;

Server.Transfer（" foo） .aspx"，true）;

}

希望这些有帮助。此外，如果您有任何不清楚的地方，请随时在这里发布

。谢谢。


问候，


Steven Cheng

微软在线支持


安全！ www.microsoft.com/security

（此帖子按原样提供，不作任何保证，并且不授予

权利。）

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

您好史蒂夫，谢谢你的回复。

我必须使用Server.TRansfer，变量设置为true，因为我需要

Forms Collection。

检查（IsPostBack）不起作用（如KB文章所说）

PostBack没有最终确定，所以PostBack值总是正确的，对吧？

我发现了这个
http://www.mail-archive.com/ad******.../msg06214.html
关于Service Pack 1之后相同问题的讨论......你能否找到更多关于这个问题的内容，因为看起来它不仅仅是我？


谢谢！
Alexander

" Steven Cheng [MSFT]"写道：

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:

嗨亚历山大，

感谢您的发布。至于你提到的问题，我已经查过了这篇文章，似乎kb文章没有详细解释原因。另外，我觉得很奇怪kb说的
安装了最新的.net 1.1 sp之后问题可能会解决，但是之后你仍然感受到它
，是吗？

无论如何，我会解释一下问题的根本原因首先：
=====================================原因：这是由于Server.Transfer方法的行为发生了变化。
从.NET版本1.0到1.1，Server.Transfer的行为有所不同。在1.0版本中，
Server.Transfer保留了Forms集合和QueryString
属性，并且
将Transfer方法视为回发的一部分。因此，
Page.IsPostBack
属性设置为true。最初版本1.1，转移不被视为回发的一部分，而Page.IsPostBack设置为false，即使Server.Transfer
转移回自身。通过821758的修复，将
v1.0的功能添加到v1.1中 - 也就是说，IsPostBack设置为true并保留表单
集合默认情况下。如果一个页面转移到自身，它将被视为回发，但是，使用这样的回发页面对象被保留，所以当
回发发生时触发server.transfer的事件将被解雇了
。如果在事件中没有捕获此回发事件，将再次执行Server.Transfer方法
。在所有后续传输中，将发生相同的过程
警告
页面反复传输到自身，直到使用所有堆栈空间并且生成堆栈
溢出异常。
===========================================

使用带有Server.Transfer的false属性将解决问题，例如：

Server.Transfer（''selfpage.aspx''，false）;

然而，这将'转移到自己页面将不再有访问权限表格
集合。如果需要维护Forms集合作为
postback的一部分，则应该在事件中添加一些额外的代码来触发Server.Transfer
调用以检查IsPostBack或其他会话变量表示
传输已发生且不应再次执行。例如，以下代码中的任何一个将保持Server.Transfer不会在随后的
回发中执行：
选项一：检查回发
If（！IsPostBack） ）
{/> Server.Transfer（" webform1.aspx"，true）
{
选项二：设置一个用作标志的页面项目
if（ Context.Items [" Transfered"] == null）
{/> Context.Items [" Transfered"] = new object（）;
Server.Transfer（" foo.aspx" ;，true）;
}

希望这些有帮助。此外，如果您有任何不清楚的地方，请随时在此处发布。谢谢。

问候，

Steven Cheng
微软在线支持

获得安全！ www.microsoft.com/security
（此帖已提供按原样，没有任何保证，也没有赋予
权利。）

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

嗨亚历山大，


感谢您的跟进。在对产品的已知

问题列表进行进一步检查后。当我们使用第二个参数调用server.transfer作为true时，似乎这仍然是asp.net的现有问题。你提到的kb文章



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


可以解决此问题。但是，.net1.1中的分辨率sp1它提到了
意味着在sp1.1之后Server.Transfer会有以下

的新行为：

===============================

Server.Transfer调用结果

Server.Transfer（不同页面，false）查询字符串数据被删除，

表单数据集合被删除。

Server.Transfer（不同页面）删除查询字符串数据，并保留表单

数据集合。

Server.Transfer（不同页面，true）查询字符串数据被保留，并且
$保留b $ b表单数据集合。

Server.Transfer（同一页面，false）查询字符串数据被删除，表格

数据收集被删除。

Server.Transfer（同一页）查询字符串数据被删除，表单数据

集合被保留。

Server.Transfer（同一页面，true）保存查询字符串数据，并保留表格

数据收集。

= ================================

并根据原因这个问题（我在上一个回复中提到过），如果我们用第二个

参数调用sever.transfer为true，那么
仍将导致stackoverflow在回发活动中。


目前我认为您可以尝试以下解决方法：

================ ===========

选项二：设置一个用作标志的页面项目

if（Context.Items [" Transfered]] == null）

{

Context.Items [" Transfered"] = new object（）;

Server.Transfer（" foo.aspx"，true）;

}

========================= =====


它在请求的上下文集合中添加了一个标记项，并将阻止

无限循环。


如果有帮助，请试试让我知道。此外，由于这是一个已知的问题，我很抱歉给您带来的任何不便。


问候，


Steven Cheng

Microsoft在线支持


安全！ www.microsoft.com/security

（此帖子按原样提供，不作任何保证，并且不授予

权利。）

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

这篇关于使用Server.Transfer时无限循环的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！