468,272 Members | 2,070 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,272 developers. It's quick & easy.

Response.Redirect vs. Server.Transfer - using ~ operator

I apologize in advance for the length of this post. I wanted to get as
much detail as possible in here.

We have 1 web app that contains the functionality to do some single
sign-on logic. The flow is

1. Welcome page
2. Login Page (where the SSO actually occurs)
3. Welcome page
4. Default page

We have a separate web app that also needs to use the SSO
functionality, so rather than duplicating it, it redirects to the
pages within the first app. So the workflow for the second app
becomes

1. Welcome page (App #2)
2. Login Page (App #1 - where the SSO actually occurs, but this time
passing a return URL)
3. Welcome Page (App #1 - still passing the Return URL)
4. Return URL (App #2)

Everything is fine with the first app by itself. Essentially, the last
line in that page is

Response.Redirect("~/Login/Welcome.aspx");

and this works fine. In the second scenario, since the return URL is
being passed, the line becomes

Response.Redirect("~/Login/Welcome.aspx?ReturnURL=http://App2/
default.aspx");

This generates an application error with a message of

"/App1/Login/~/Login/Welcome.aspx?ReturnURL=http://App2/default.aspx"
cannot be found.

So it looks like it sees the '~' as a literal part of the path and
does not actually resolve it correctly in the second scenario. It
looks like it assumes that it needs to append the relative path to the
front of the URL passed to Response.Redirect. If we use
Server.Transfer instead, it works just fine. Does anyone know why this
is the case?
Jun 27 '08 #1
3 3224
I think the problem is that you do not encode URL correctly.
Must be something like
Response.Redirect("~/Login/Welcome.aspx?ReturnURL=" +
Server.UrlEncode(http://App2/default.aspx") );

George.
<ja************@gmail.comwrote in message
news:e1**********************************@26g2000h sk.googlegroups.com...
>I apologize in advance for the length of this post. I wanted to get as
much detail as possible in here.

We have 1 web app that contains the functionality to do some single
sign-on logic. The flow is

1. Welcome page
2. Login Page (where the SSO actually occurs)
3. Welcome page
4. Default page

We have a separate web app that also needs to use the SSO
functionality, so rather than duplicating it, it redirects to the
pages within the first app. So the workflow for the second app
becomes

1. Welcome page (App #2)
2. Login Page (App #1 - where the SSO actually occurs, but this time
passing a return URL)
3. Welcome Page (App #1 - still passing the Return URL)
4. Return URL (App #2)

Everything is fine with the first app by itself. Essentially, the last
line in that page is

Response.Redirect("~/Login/Welcome.aspx");

and this works fine. In the second scenario, since the return URL is
being passed, the line becomes

Response.Redirect("~/Login/Welcome.aspx?ReturnURL=http://App2/
default.aspx");

This generates an application error with a message of

"/App1/Login/~/Login/Welcome.aspx?ReturnURL=http://App2/default.aspx"
cannot be found.

So it looks like it sees the '~' as a literal part of the path and
does not actually resolve it correctly in the second scenario. It
looks like it assumes that it needs to append the relative path to the
front of the URL passed to Response.Redirect. If we use
Server.Transfer instead, it works just fine. Does anyone know why this
is the case?

Jun 27 '08 #2
Response.Redirect actually goes back to the browser and tells the *browser*
to request the new "page". Server.Transfer all happens on the server, and
the new page is simply sent out to the browser, with no new round trip to
the browser at all.
Peter
<ja************@gmail.comwrote in message
news:e1**********************************@26g2000h sk.googlegroups.com...
>I apologize in advance for the length of this post. I wanted to get as
much detail as possible in here.

We have 1 web app that contains the functionality to do some single
sign-on logic. The flow is

1. Welcome page
2. Login Page (where the SSO actually occurs)
3. Welcome page
4. Default page

We have a separate web app that also needs to use the SSO
functionality, so rather than duplicating it, it redirects to the
pages within the first app. So the workflow for the second app
becomes

1. Welcome page (App #2)
2. Login Page (App #1 - where the SSO actually occurs, but this time
passing a return URL)
3. Welcome Page (App #1 - still passing the Return URL)
4. Return URL (App #2)

Everything is fine with the first app by itself. Essentially, the last
line in that page is

Response.Redirect("~/Login/Welcome.aspx");

and this works fine. In the second scenario, since the return URL is
being passed, the line becomes

Response.Redirect("~/Login/Welcome.aspx?ReturnURL=http://App2/
default.aspx");

This generates an application error with a message of

"/App1/Login/~/Login/Welcome.aspx?ReturnURL=http://App2/default.aspx"
cannot be found.

So it looks like it sees the '~' as a literal part of the path and
does not actually resolve it correctly in the second scenario. It
looks like it assumes that it needs to append the relative path to the
front of the URL passed to Response.Redirect. If we use
Server.Transfer instead, it works just fine. Does anyone know why this
is the case?
Jun 27 '08 #3
I want to add....
Do not use Server.Transfer if you do not know all implications...
Response.Redirect and Server.Transfer are not interchangeable.

When using Server.Transfer ASP.NET is actually using new .aspx page (the one
you transferred to).
But the browser still thinks that you are at old .asp page and POST back
will go to old .aspx page......
Hence a lot of problems.....
George.
"Peter Bromberg [C# MVP]" <pb*******@nospammin.yahoo.comwrote in message
news:1A**********************************@microsof t.com...
Response.Redirect actually goes back to the browser and tells the
*browser* to request the new "page". Server.Transfer all happens on the
server, and the new page is simply sent out to the browser, with no new
round trip to the browser at all.
Peter
<ja************@gmail.comwrote in message
news:e1**********************************@26g2000h sk.googlegroups.com...
>>I apologize in advance for the length of this post. I wanted to get as
much detail as possible in here.

We have 1 web app that contains the functionality to do some single
sign-on logic. The flow is

1. Welcome page
2. Login Page (where the SSO actually occurs)
3. Welcome page
4. Default page

We have a separate web app that also needs to use the SSO
functionality, so rather than duplicating it, it redirects to the
pages within the first app. So the workflow for the second app
becomes

1. Welcome page (App #2)
2. Login Page (App #1 - where the SSO actually occurs, but this time
passing a return URL)
3. Welcome Page (App #1 - still passing the Return URL)
4. Return URL (App #2)

Everything is fine with the first app by itself. Essentially, the last
line in that page is

Response.Redirect("~/Login/Welcome.aspx");

and this works fine. In the second scenario, since the return URL is
being passed, the line becomes

Response.Redirect("~/Login/Welcome.aspx?ReturnURL=http://App2/
default.aspx");

This generates an application error with a message of

"/App1/Login/~/Login/Welcome.aspx?ReturnURL=http://App2/default.aspx"
cannot be found.

So it looks like it sees the '~' as a literal part of the path and
does not actually resolve it correctly in the second scenario. It
looks like it assumes that it needs to append the relative path to the
front of the URL passed to Response.Redirect. If we use
Server.Transfer instead, it works just fine. Does anyone know why this
is the case?

Jun 27 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Justin | last post: by
4 posts views Thread by Harsh Thakur | last post: by
3 posts views Thread by Grant | last post: by
2 posts views Thread by Nathan Sokalski | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.