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
<> wrote in message
news:e163c25e-6f8f-40e0-92a4-...
>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?
|
Similar Threads
