What is the difference between server.transfer and response.redirect?
For Answers, see/post comments
Discussion List
-
▼
2008
(95)
- ► 07/20 - 07/27 (6)
- ▼ 07/13 - 07/20 (10)
- ► 07/06 - 07/13 (4)
- ► 06/15 - 06/22 (8)
- ► 05/25 - 06/01 (6)
- ► 05/18 - 05/25 (13)
- ► 05/11 - 05/18 (12)
- ► 05/04 - 05/11 (21)
- ► 04/27 - 05/04 (15)
4 comments:
hi,
A common misconception is the difference between server.Transfer and Response.Redirect in ASP.NET applications. Redirect and Transfer both cause a new page to be processed, but the interaction between the client (web browser) and server (ASP.NET) is different in each situation.
Redirect: A redirect is just a suggestion – it’s like saying to the client “Hey, you might want to look at this”. All you tell the client is the new URL to look at, and if they comply, they do a second request for the new URL.
If you want to pass state from the source page to the new page, you have to pass it either on the URL (such as a database key, or message string), or you can store it in the Session object (caveat: there may be more than one browser window, and they’ll all use the same session object).
e.g. Redirect to the new.aspx page, passing an ID on the query string. "true" stops processing the current page:
Response.Redirect("new.aspx?id=34", true);
Transfer: A transfer happens without the client knowing – it’s the equivalent of a client requesting one page, but being given another. As far as the client knows, they are still visiting the original URL.
Sharing state between pages is much easier using Server.Transfer – you can put values into the Context.Items dictionary, which is similar to Session and Application, except that it lasts only for the current request. (search for HttpContext in MSDN). The page receiving postback can process data, store values in the Context, and then Transfer to a page that uses the values.
e.g. Store a message in the context dictionary, and transfer to the default.aspx page (which can then display the message):
Context.Items["Message"] = "Your password was changed successfully";
Server.Transfer("default.aspx");
* Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
* Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
* Server.Transfer has an optional parameter to pass the form data to the new page.
* Since the release version, this no longer works, because the Viewstate now has more security by default (The EnableViewStateMac defaults to true), so the new page isn’t able to access the form data. You can still access the values of the original page in the new page, by requesting the original handler:
Server Transfer
1. Client Request Page HelloWorld.ASPX
2. Server.Transfer -> Server send a different page to the client
3. Client Receives Page still thinking it's HelloWorld.ASPX.
4. Client's URL (Address bar) remains HelloWorld.ASPX since the page was
sent on the server side and the client doesn't know a different page was
sent.
Response.Redirect
1. Client Requests Page HelloWorld.ASPX
2. Response.Redirect -> Server sends a HTTP header informing that the
user should redirect. 3. Client sees the redirect notice and requests
AnotherPage.ASPX 4. Server sends AnotherPage.ASPX
5. Client's URL (address bar) shows AnotherPage.ASPX
http://www.dotnetspider.com/resources/930-What-e-difference-between-Server-Transfer.aspx
Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
Server.Transfer has an optional parameter to pass the form data to the new page.
Both "Server" and "Response" are objects of ASP.NET. Server.Transfer and Response.Redirect both are used to transfer a user from one page to another. But there is an underlying difference.
The Response.Redirect statement sends a command back to the browser to request the next page from the server. This extra round-trip is often inefficient and unnecessary, but this established standard works very well. By the time Page2 is requested, Page1 has been flushed from the server’s memory and no information can be retrieved about it unless the developer explicitly saved the information using some technique like session, cookie, application, cache etc.
The more efficient Server.Transfer method simply renders the next page to the browser without an extra round trip. Variables can stay in scope and Page2 can read properties directly from Page1 because it’s still in memory. This technique would be ideal if it wasn’t for the fact that the browser is never notified that the page has changed. Therefore, the address bar in the browser will still show “Page1.aspx” even though the Server.Transfer statement actually caused Page2.aspx to be rendered instead. This may occasionally be a good thing from a security perspective, it often causes problems related to the browser being out of touch with the server. Say, the user reloads the page, the browser will request Page1.aspx instead of the true page (Page2.aspx) that they were viewing. In most cases, Response.Redirect and Server.Transfer can be used interchangeably. But in some cases, efficiency or usability may be the deciding factor in choosing.
Post a Comment