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/advanced.../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:
[color=blue]
> 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.)
>
>
>
>
>[/color]