Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Forums » .NET » ASP.NET »
diff b/w server.Execute and resposce.redirect
Posted Date: 26 Jul 2008 Posted By: syam kumar Member Level: Silver Points: 1
Responses:
8
|
diff b/w server.Execute and resposce.redirect
|
Responses
|
| Author: nirmala 26 Jul 2008 | Member Level: Gold | Rating:  Points: 6 |
In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they're difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems.
As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.
| | Author: Ratheesh 29 Jul 2008 | Member Level: Gold | Rating: Points: 1 |
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");
Caveats:
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:
Page originalPage = (Page)Context.Handler;
TextBox textBox1 = (TextBox)originalPage.FindControl("textBox1");
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
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");
Caveats:
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:
Page originalPage = (Page)Context.Handler;
TextBox textBox1 = (TextBox)originalPage.FindControl("textBox1");
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
Server.Execute (path) execute the ASP script specified by path. If path is an absolute path, it should be for an ASP page within the same application space (the same folder or one of its subfolder) path may contain query string date.
Suppose for a moment that you want some information at the top and bottom of every page on your site. This might be some graphics, links, contact information, and so on. One way you could do this is to include some file at the top of every page and another one at the bottom. This will work, but it lacks some flexibility. You might decide that you want two different ways to view each page. If you want to keep your options open for expansion, you might decide to use server. Execute.
Transferring Control to another Page
Server.Transfer is used to transfer control to another ASP page. When it is called, all the data related to the calling page is transferred to the new page. This means that if variables of session or application scope has been given values, those values are kept in the new page. State information and values for the built-in objects are transferred, too. Also the contents of the request collections are kept and are available to the new page.
You can even perform a server.Transfer between two pages in separate applications. In this case, the value of the application variables and objects will be the same as if the second page were in the same application as the first. That is, the values of application scope variables and objects are kept after the transfer.
Demonstrates How to Use Server.Execute
<%@ LANGUAGE=VBSCRIPT %>
<% Option Explicit %>
<HTML>
<BODY>
<%
Response.Write( “I am in page 1 <BR>”)
Server.Transfer(“page2.asp”)
Response.Write(“Back in page 1”)
%>
< / BODY>
</HTML>
This page is almost identical to page1.asp. the only difference is that line 7 uses a server. Transfer in place of the server.Execute. You can see the result of this listing. Notice that in this version, the third line is not printed. That is because you never return to the calling page when you do a server.Transfer. In this regard, server.Transfer may be used a bit like the Response. Redirect.
Redirect tells the user’s browser to make a new request. This result in the creation of a new object context, which is used to contain the session and request objects as well as some server variables. Sometime when you want to send the user to different page, you will want a new object context to be created. In such case, you should use Response.Redirect.
If you do not need a new object context, you are probably better off using server.Transfer, which is faster because it dose not involve as many communications or the creation of a new object context.
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
At that time to run a page, then continue with another action in a different page you had a few choices:
1) Include the page, most likely this didn't work easily due to order of page rendering, etc. potential duplicate subroutine names, conficts, etc.
2) Redirect the browser, which sent back the header for the browser to reload a different url for the user to see. This works as if the user went to a page, then clicked the link to follow to the next page (which happens automatically when you do a response.redirect).
The concept of transferring the user on the server was new at that time. The goal was to be able to move to the next page WITHOUT the client (or their browser) having to do any work (reduced network traffic, maintain the original url, etc.).
You also have Server.Execute to consider in this mix.
Sometimes this is "the same" to the programmer / webmaster, other times it may not be.
Perhaps you want to render a header on a page or something like that, then continue executing another page - This can be done easily with server.transfer - Where response.redirect would start a new page, and couldn't easily accomplish this goal.
Today you could probably substitute server.transfer in most cases, you could clear the response output before the transfer and things would work, at least in what is displayed, just like a response.write.
One difference I can think of is if the user tries to bookmark or refresh they will have the old url, and again be server.transferred. This may be preferred on not desired depending on your circumstances - For example if you were trying to track something that happens once a server.transfer may not meet your goal, where a response.redirect the user is on the other url and if they refresh they will still be on the other url.
I hope this helps explain the difference some - It can be confusing. Please write to suggest@aspdeveloper.net with any better examples of when it would be appropriate, versus inappropriate to use either method - This may help clarify things for others.
http://www.aspdeveloper.net/tiki-index.php?page=ASPFAQDiffRedirectTransfer
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
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");
Caveats:
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:
Page originalPage = (Page)Context.Handler;
TextBox textBox1 = (TextBox)originalPage.FindControl("textBox1");
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
Server.Transfer
ASP developers have used Response.Redirect since the days of ASP 1.0 to redirect the browser to another page. Perhaps, like me, you thought this was all occurring on the server and was thus a fairly efficient operation, but that's not how it works. When the ASP engine encounters a Response.Redirect method, it stops the processing of the current page and sends an HTTP redirection header (302 Redirect) to the client, informing it that the page it requested has moved and can be found at a different URL. When this response is sent to the browser, the browser requests the new URL and the ASP engine sends the new page to the client. Thus, the redirection of a page using Response.Redirect requires an extra client/server round trip.
Server.Transfer works differently than Response.Redirect. When the ASP engine encounters a Server.Transfer method on the page, it stops processing the page and sends the new page to the client in the response. That is, Server.Transfer substitutes the request for one page with another without involving an extra round trip between the server and the browser. In fact, as far as the browser is concerned, it received the page it originally requested. Let's illustrate with an example. Say you wished to branch in your ASP code and send users to one page or another based on whether they were using Internet Explorer or some other browser. The following code from Redirect1.asp accomplishes this employing the Browser Capabilities component and the Response.Redirect method:
Not All Good
Server.Transfer has several advantages over Response.Redirect:
• Because it saves a round trip between the server and the browser it's faster and reduces the load on the Web server.
• The Response querystring and form collections are preserved during the transfer. As a result, you don't need to worry about reposting form and querystring data to the new page.
However, Server.Transfer does have a few disadvantages:
• You can only use Server.Transfer to redirect to a page on the same Web server.
• You can't pass a querystring to the new page. (However, remember that the querystring passed to the page executing the transfer will automatically be passed along to the new page.) If you try to pass a querystring to the new page, you will trigger an ASP error.
• The browser is never notified of the new page, which can cause problems with relative links in some cases.
Server.Execute
Another new Server method introduced by ASP 3.0 is Server.Execute. Use Server.Execute to run a chunk of ASP code on another page, returning to the original page when the code is done executing. In many ways, Server.Execute serves a similar purpose to server-side includes. However, because Server.Execute is an ASP method rather than an HTML comment, you can use it to conditionally execute scripts and avoid including huge include files. Server-side includes are executed prior to any ASP code and thus can't be executed conditionally.
| | Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
Server.Execute (path) execute the ASP script specified by path. If path is an absolute path, it should be for an ASP page within the same application space (the same folder or one of its subfolder) path may contain query string date.
Suppose for a moment that you want some information at the top and bottom of every page on your site. This might be some graphics, links, contact information, and so on. One way you could do this is to include some file at the top of every page and another one at the bottom. This will work, but it lacks some flexibility. You might decide that you want two different ways to view each page. If you want to keep your options open for expansion, you might decide to use server. Execute.
Transferring Control to another Page
Server.Transfer is used to transfer control to another ASP page. When it is called, all the data related to the calling page is transferred to the new page. This means that if variables of session or application scope has been given values, those values are kept in the new page. State information and values for the built-in objects are transferred, too. Also the contents of the request collections are kept and are available to the new page.
You can even perform a server.Transfer between two pages in separate applications. In this case, the value of the application variables and objects will be the same as if the second page were in the same application as the first. That is, the values of application scope variables and objects are kept after the transfer.
Demonstrates How to Use Server.Execute
<%@ LANGUAGE=VBSCRIPT %>
<% Option Explicit %>
<HTML>
<BODY>
<%
Response.Write( “I am in page 1 <BR>”)
Server.Transfer(“page2.asp”)
Response.Write(“Back in page 1”)
%>
< / BODY>
</HTML>
This page is almost identical to page1.asp. the only difference is that line 7 uses a server. Transfer in place of the server.Execute. You can see the result of this listing. Notice that in this version, the third line is not printed. That is because you never return to the calling page when you do a server.Transfer. In this regard, server.Transfer may be used a bit like the Response. Redirect.
Redirect tells the user’s browser to make a new request. This result in the creation of a new object context, which is used to contain the session and request objects as well as some server variables. Sometime when you want to send the user to different page, you will want a new object context to be created. In such case, you should use Response.Redirect.
If you do not need a new object context, you are probably better off using server.Transfer, which is faster because it dose not involve as many communications or the creation of a new object context.
|
| Post Reply |
|
|
|
 | | This thread is locked for new responses. Please post your comments and questions as a separate thread.
If required, refer to the URL of this page in your new post. |
|
|
|
|