Server.Transfer goes to wrong page

[Keith Patrick]

I have an app where a Shockwave splash animation starts off my app and then
sets its parent iframe's src to the value of a default page "BasicReports".
BasicReports has a link to another report page, but when I click it and
redirect via Server.Transfer (using both values for preserveForm), the first
time, it loads up BasicReports again. If I click BasicReports *again*, then
it transfers to the correct page. Is there a known behavior/bug with
Server.Transfer that would cause this? Only thing I can remotely think of
is that the server is not aware of the page change due to it being set via
iframe.attributes["src"] = "NewReport.aspx" and is therefore going to the
first place it knows, but if that is the case, am I screwed?

 

[Keith Patrick]

Well, I took all the shockwave stuff out altogether, and Server.Transfer
*still* (even after verifying the URL as well) returns the user to the same
page the first time the transfer happens. Subsequent attempts work, but I
can't for the life of me figure out where ASP is getting the command to go
to the wrong page.
BTW: I cannot use Response.Redirect because I have to simulate a POST based
on a querystring, and .Net has all of the Response collections that I can
use set to read-only, leaving me to just use Server.Items.

BTW2: I have tried this with SmartNav both on and off, and it does the same
thing in each case, leading me to think that Server.Transfer has some issue
with iframes. Gonna see if MS' knowledge base has improved its hit-to-noise
ratio to maybe find a way out of this mess.

 

[Alvin Bruney [MVP]]

post a small but complete sample program demonstrating the problem

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
----------------------------------------------------------

Well, I took all the shockwave stuff out altogether, and Server.Transfer
*still* (even after verifying the URL as well) returns the user to the
same page the first time the transfer happens. Subsequent attempts work,
but I can't for the life of me figure out where ASP is getting the command
to go to the wrong page.
BTW: I cannot use Response.Redirect because I have to simulate a POST
based on a querystring, and .Net has all of the Response collections that
I can use set to read-only, leaving me to just use Server.Items.

BTW2: I have tried this with SmartNav both on and off, and it does the
same thing in each case, leading me to think that Server.Transfer has some
issue with iframes. Gonna see if MS' knowledge base has improved its
hit-to-noise ratio to maybe find a way out of this mess.

I have an app where a Shockwave splash animation starts off my app and
then sets its parent iframe's src to the value of a default page
"BasicReports". BasicReports has a link to another report page, but when I
click it and redirect via Server.Transfer (using both values for
preserveForm), the first time, it loads up BasicReports again. If I click
BasicReports *again*, then it transfers to the correct page. Is there a
known behavior/bug with Server.Transfer that would cause this? Only thing
I can remotely think of is that the server is not aware of the page change
due to it being set via iframe.attributes["src"] = "NewReport.aspx" and is
therefore going to the first place it knows, but if that is the case, am I
screwed?

 

[Keith Patrick]

Found the problem: We had our base page using an MSDN sample for showing
long-running pages as a countdown during load. The Server.Transfer call
moved Request.Params out of the read-only area of the query string and into
the Context.Items collection, which the client-side long-running-code stuff
could not detect, thus sending it back to the page that called it. Because
it was a client-side redirect, I never caught it in my debugger. I'm going
to change around my "redirect" code to ignore certain Request.Params, such
as that one and any session/cookie stuff so that only app-defined vars get
moved around like that.

Well, I took all the shockwave stuff out altogether, and Server.Transfer
*still* (even after verifying the URL as well) returns the user to the
same page the first time the transfer happens. Subsequent attempts work,
but I can't for the life of me figure out where ASP is getting the command
to go to the wrong page.
BTW: I cannot use Response.Redirect because I have to simulate a POST
based on a querystring, and .Net has all of the Response collections that
I can use set to read-only, leaving me to just use Server.Items.

BTW2: I have tried this with SmartNav both on and off, and it does the
same thing in each case, leading me to think that Server.Transfer has some
issue with iframes. Gonna see if MS' knowledge base has improved its
hit-to-noise ratio to maybe find a way out of this mess.

I have an app where a Shockwave splash animation starts off my app and
then sets its parent iframe's src to the value of a default page
"BasicReports". BasicReports has a link to another report page, but when I
click it and redirect via Server.Transfer (using both values for
preserveForm), the first time, it loads up BasicReports again. If I click
BasicReports *again*, then it transfers to the correct page. Is there a
known behavior/bug with Server.Transfer that would cause this? Only thing
I can remotely think of is that the server is not aware of the page change
due to it being set via iframe.attributes["src"] = "NewReport.aspx" and is
therefore going to the first place it knows, but if that is the case, am I
screwed?