Response.Redirect simply sends a message down to the browser, telling it to move to another page. So, you may run code like:
Response.Redirect(“WebForm2.aspx”)
Or
Response.Redirect(http://www.google.com)
To send the user to another page.
With a call to Response.Redirect, the server basically sends an HTTP header back to the client browser with an HTTP status code stating that the object has moved along with the new location to find it.
See the snippet of an example HTTP header below when
Response.Redirect(“somewhere/newlocation.aspx”) is called.
HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.0
Location: somewhere/newlocation.aspx
This tells the browser that the requested resource (page) can be found at a new location, namely somewhere/newlocation.aspx. The browser then initials another request (assuming it supports redirects) to somewhere/newlocation.aspx loading its contents in the browser. This results in two requests by the browser.
One ramification of this is that if the initial request was a form POST, the posted from fields are not available in the second request. Likewise query string parameters are unavailable unless the page that issues the redirect explicitly tacks them on. Also, since the browser initiates the second request, it is possible to redirect to a page on an external site.
Server.Transfer is similar in that it sends the user to another page with a statement such as Server.Transfer(“WebForm2.aspx”). However, the statement has a number of distinct advantages and disadvantages.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the “focus” on the Web server and transfers the request. This means you don’t get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
Because the “transfer” process can work on only those sites running on the server, you can’t use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That’s not all: The Server.Transfer method also has a second parameter – “preserveFrom”. If you set this to True, using a statement such as Server.Transfer(“WebForm2.aspx”, True), the existing query string and any form variables will still be available to the page you are transferring to.
Server.Transfer transfers execution from the first page to the second page on the server. As far as the browser client is concerned, it made one request and the initial page is the one responding with content (this point often confuses new ASP.NET developers as the browser still shows the URL of the initial page even though the content is generated by the second page. It all makes sense when you understand what is happening.).
The benefit of this approach is one less round trip to the server from the client browser. Also, any posted form variables and query string parameters are available to the second page as well (however these can be cleared by passing in false for the second parameter).
One thing to be aware of is that if the first page wrote something to the Response buffer and you don’t clear it, then any output from the second page will be appended to the output of the first. This is often the cause of a weird behavior where it seems that a page is returning two different pages. Also, since the transfer happens on the server, you cannot transfer a request to an external site.
Tuesday, February 23, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment