473,289 Members | 2,091 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,289 software developers and data experts.

Response.Redirect & Server.Execute

RN1
When a server encounters the line

Response.Redirect("abcd.asp")

in a ASP script, the server tells the browser that it has to be
redirected to another page (which is abcd.asp, in this case). The
browser then makes a new request to the server to redirect itself to
abcd.asp after which the user gets redirected to abcd.asp.

But in case of Server.Execute (or Server.Transfer), when the server
encounters the line

Server.Execute("abcd.asp")

in a ASP script, unlike Response.Redirect, the server DOES NOT tell
the browser that it has to be redirected to another page. The server
simply executes the line Server.Execute("abcd.asp"), without telling
the browser anything about it & takes the user to abcd.asp. This means
Response.Redirect involves an additional server-client round trip
which isn't the case with Server.Execute (or Server.Transfer).

Whatever I have said above, is that correct? If not, please do correct
me.
Dec 17 '07 #1
9 4299

"RN1" <rn**@rediffmail.comwrote in message
news:78**********************************@s8g2000p rg.googlegroups.com...
When a server encounters the line

Response.Redirect("abcd.asp")

in a ASP script, the server tells the browser that it has to be
redirected to another page (which is abcd.asp, in this case). The
browser then makes a new request to the server to redirect itself to
abcd.asp after which the user gets redirected to abcd.asp.

But in case of Server.Execute (or Server.Transfer), when the server
encounters the line

Server.Execute("abcd.asp")

in a ASP script, unlike Response.Redirect, the server DOES NOT tell
the browser that it has to be redirected to another page. The server
simply executes the line Server.Execute("abcd.asp"), without telling
the browser anything about it & takes the user to abcd.asp. This means
Response.Redirect involves an additional server-client round trip
which isn't the case with Server.Execute (or Server.Transfer).

Whatever I have said above, is that correct? If not, please do correct
me.
Largely correct. Except that Response.Redirect and Server.Transfer are the
two methods that "compete" with eachother in terms of what they do.
Server.Execute will cause the server to process whichever file it is told
to, but will continue to process further code on the page after the
Server.Execute call was made (unless the code in the target file to be
executed prevents that from happening eg by including a Response.Redirect,
Response.End or Server.Transfer call). Server.Transfer moves the execution
to a different resource entirely, as does Response.Redirect.
--
Mike Brind
Dec 17 '07 #2
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:
Largely correct. Except that Response.Redirect and Server.Transfer
are the two methods that "compete" with eachother in terms of what
they do. Server.Execute will cause the server to process whichever
file it is told to, but will continue to process further code on the
page after the Server.Execute call was made (unless the code in the
target file to be executed prevents that from happening eg by
including a Response.Redirect, Response.End or Server.Transfer call).
So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============

?

============================
Server.Transfer moves the execution to a different resource entirely,
as does Response.Redirect.
Not exactly.

Response.Redirect

just asks [in the header] the client to do a redirect,
and it is up to the client to comply.

Not all clients are browsers.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 17 '07 #3

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn********************@194.109.133.242...
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:
>Largely correct. Except that Response.Redirect and Server.Transfer
are the two methods that "compete" with eachother in terms of what
they do. Server.Execute will cause the server to process whichever
file it is told to, but will continue to process further code on the
page after the Server.Execute call was made (unless the code in the
target file to be executed prevents that from happening eg by
including a Response.Redirect, Response.End or Server.Transfer call).

So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============

?

============================
I don't understand your question. Or the point behind it. Did I say they
were effectively the same?
>
>Server.Transfer moves the execution to a different resource entirely,
as does Response.Redirect.

Not exactly.

Response.Redirect

just asks [in the header] the client to do a redirect,
and it is up to the client to comply.

Not all clients are browsers.
OK. I'll rephrase. Server.Transfer *effectively* moves the execution to a
different resource entirely, as does Response.Redirect. Depending on the
client's ability to understand and process headers in the way that you would
hope that Response.Redirect will act, in an ideal world where someone is
accessing your web site using one of the common web browsers. But don't
count on it working if people are using refrigerators to access your web
site.
Dec 17 '07 #4
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:
>
"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn********************@194.109.133.242...
>Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:
>>Largely correct. Except that Response.Redirect and Server.Transfer
are the two methods that "compete" with eachother in terms of what
they do. Server.Execute will cause the server to process whichever
file it is told to, but will continue to process further code on the
page after the Server.Execute call was made (unless the code in the
target file to be executed prevents that from happening eg by
including a Response.Redirect, Response.End or Server.Transfer
call).

So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============

?

============================

I don't understand your question.
I was just asking.
Or the point behind it.
Which of the two, Mike?
Did I say
they were effectively the same?
>>
>>Server.Transfer moves the execution to a different resource
entirely, as does Response.Redirect.

Not exactly.

Response.Redirect

just asks [in the header] the client to do a redirect,
and it is up to the client to comply.

Not all clients are browsers.

OK. I'll rephrase. Server.Transfer *effectively* moves the execution
to a different resource entirely, as does Response.Redirect. Depending
on the client's ability to understand and process headers in the way
that you would hope that Response.Redirect will act, in an ideal world
where someone is accessing your web site using one of the common web
browsers. But don't count on it working if people are using
refrigerators to access your web site.
Indeed refrigerators or just download the page using AJAX-technology in a
browser, using cscript/wscript, or even using server.xmlhttp.

The nice, or bad, thing is that Response.Redirect will actualize the
browser address bar, if not in a frame structure.

Another nice, or bad, thing is that Response.Redirect will make a new
page, with it's own css style and other settings and with it's own global
clientside javascript environment.

Another nice, or bad, thing is that it can work cross domain.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 17 '07 #5
RN1
On Dec 18, 12:52 am, "Evertjan." <exjxw.hannivo...@interxnl.net>
wrote:
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:
Largely correct. Except that Response.Redirect and Server.Transfer
are the two methods that "compete" with eachother in terms of what
they do. Server.Execute will cause the server to process whichever
file it is told to, but will continue to process further code on the
page after the Server.Execute call was made (unless the code in the
target file to be executed prevents that from happening eg by
including a Response.Redirect, Response.End or Server.Transfer call).

So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============

?

============================
Server.Transfer moves the execution to a different resource entirely,
as does Response.Redirect.

Not exactly.

Response.Redirect

just asks [in the header] the client to do a redirect,
and it is up to the client to comply.

Not all clients are browsers.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Assuming that there isn't any code to be executed between
Server.Execute "f2.asp" & Response.End in the 2nd version of f1.asp
(i.e. the line Response.End comes immediately after the line
Server.Execute "f2.asp"), then the 2 versions of f1.asp may not be the
same effectively but the output to the browser will be the same, isn't
it?

======f1.asp======
<%
Response.Write("I am in Page1<br>")
Server.Transfer("f2.asp")
%>
================

======f1.asp======
<%
Response.Write("I am in Page1<br>")
Server.Execute("f2.asp")
Response.End
%>
================

======f2.asp======
<%
Response.Write("I am in Page2")
%>
================

With the 1st version of f1.asp (Server.Transfer), the output to the
browser will be

------------------------------
I am in Page1
I am in Page2
------------------------------

Same will be the output with the 2nd version of f1.asp
(Server.Execute) since it will first execute Response.Write("I am in
Page1<br>"), then go to f2.asp & execute the line Response.Write("I am
in Page2") & finally come back to f1.asp to execute Response.End at
which point the script execution will terminate.

Please correct me if I am wrong. Moreover why won't the 2 versions of
f1.asp be effectively the same?
Dec 18 '07 #6
RN1 wrote on 18 dec 2007 in microsoft.public.inetserver.asp.general:
On Dec 18, 12:52 am, "Evertjan." wrote:
[skip]
>So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============
[skip]

[please do not quote signatures, corected]
>
Assuming that there isn't any code to be executed between
Server.Execute "f2.asp" & Response.End in the 2nd version of f1.asp
(i.e. the line Response.End comes immediately after the line
Server.Execute "f2.asp"), then the 2 versions of f1.asp may not be the
same effectively but the output to the browser will be the same, isn't
it?
That was my meaning of "effectively", yes.
======f1.asp======
<%
Response.Write("I am in Page1<br>")
Server.Transfer("f2.asp")
%>
================

======f1.asp======
<%
Response.Write("I am in Page1<br>")
Server.Execute("f2.asp")
Response.End
%>
================

======f2.asp======
<%
Response.Write("I am in Page2")
%>
================

With the 1st version of f1.asp (Server.Transfer), the output to the
browser will be

------------------------------
I am in Page1
I am in Page2
------------------------------

Same will be the output with the 2nd version of f1.asp
(Server.Execute) since it will first execute Response.Write("I am in
Page1<br>"), then go to f2.asp & execute the line Response.Write("I am
in Page2") & finally come back to f1.asp to execute Response.End at
which point the script execution will terminate.

Please correct me if I am wrong. Moreover why won't the 2 versions of
f1.asp be effectively the same?
That was my meaning of "effectively", yes.

The second version would be slightly slower, but as long as f1.asp is in
the server's ram memory, that would not account for much.

One could maintain, that, when f2.asp is a lenghty proces, the neccesity
of unnecessarily maintaining f1.asp in memory on a buzzy server could
necessitate more use of the virtual swapfile on harddisk, and so slowing
the server down.

But that is not neccessarily so on all servers, as it also depends on the
size of the installed ram memory.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 18 '07 #7
"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn********************@194.109.133.242...
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn********************@194.109.133.242...
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:

Largely correct. Except that Response.Redirect and Server.Transfer
are the two methods that "compete" with eachother in terms of what
they do. Server.Execute will cause the server to process whichever
file it is told to, but will continue to process further code on the
page after the Server.Execute call was made (unless the code in the
target file to be executed prevents that from happening eg by
including a Response.Redirect, Response.End or Server.Transfer
call).

So

=== f1.asp ===
<%
Server.Transfer "f2.asp"
%>
==============

does effectively the same as:

=== f1.asp ===
<%
Server.Execute "f2.asp"
Response.End
%>
==============

?

============================
I don't understand your question.

I was just asking.
Or the point behind it.

Which of the two, Mike?
Did I say
they were effectively the same?
>
Server.Transfer moves the execution to a different resource
entirely, as does Response.Redirect.

Not exactly.

Response.Redirect

just asks [in the header] the client to do a redirect,
and it is up to the client to comply.

Not all clients are browsers.
OK. I'll rephrase. Server.Transfer *effectively* moves the execution
to a different resource entirely, as does Response.Redirect. Depending
on the client's ability to understand and process headers in the way
that you would hope that Response.Redirect will act, in an ideal world
where someone is accessing your web site using one of the common web
browsers. But don't count on it working if people are using
refrigerators to access your web site.

Indeed refrigerators or just download the page using AJAX-technology in a
browser, using cscript/wscript, or even using server.xmlhttp.
By default XMLHTTP (server or otherwise) will follow a redirect response
siliently. You can set an option on ServerXMLHTTP to disable that though.

--
Anthony Jones - MVP ASP/ASP.NET
Dec 22 '07 #8
Anthony Jones wrote on 22 dec 2007 in
microsoft.public.inetserver.asp.general:
By default XMLHTTP (server or otherwise) will follow a redirect
response siliently. You can set an option on ServerXMLHTTP to disable
that though.
Can you give a coded example?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 22 '07 #9
Anthony Jones wrote on 26 dec 2007 in
microsoft.public.inetserver.asp.general:
>Cannot get it to work, as my

<%
server.transfer "/asp/xxx.asp"
%>

seems to return 200,

or it is xxx.asp's status 200 that is invoked anyway,
even if

oWinHTTP.Option(6) = False;

is executed [IE7 under XP].

It only applies when Response.Redirect is used. Server.Transfer
occurs purely on the server without roundtriping back to the client so
there is now
way to intercept a Server.Transfer in client code.
Ah, yes, my blind spot!

I'll try again.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 27 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: JC | last post by:
Hi, I have a simple question regarding the Response.Redirect method. Does the server stop processing the ASP code as soon as it encounters the Redirect command? Or does it ever continue to...
5
by: Paul de Goede | last post by:
I set the Response.Filter in my aspnet application but I have noticed that if you do a Server.Transfer that the filter doesn't get called. And in actual fact the response is mostly empty. It seems...
3
by: Raterus | last post by:
Anyone know how I can figure out the figure out the response.redirect trail a browser goes through when I'm using response.redirect on the server. Right now Internet Explorer just automatically...
3
by: Jed | last post by:
I have written an HttpHandler which I invoke through an ashx page. The HttpHandler does various things to process the request, then it is supposed to redirect to a confirmation page. Everything...
9
by: postings | last post by:
Just a quick question... When I do a "response.redirect" from a source webpage to a destination webpage, does the code on the source webpage carry on executing unless I put a "response.end"...
16
by: wizard04 | last post by:
On my WinXP machine, with both IE6 and Firefox 1.0, response.redirect and server.transfer take about a minute. But on my WinNT machine with IE5.5, it works instantly. What's going on?
4
by: mike.biang | last post by:
I have an ASP page that is using an XMLHTTP object to request various pages from my server. I keep a single session throughout the XMLHTTP requests by bassing the ASPSESSIONID cookie through the...
6
by: gyung | last post by:
Hi, this is my first post but I've been constantly referred to this site when I needed help. Anyway, this time I can't seem to find anything, so here goes. This is part of my case statement, and I...
4
by: nkoier | last post by:
Hi, I've been going crazy trying to figure out what's wrong with our Asp.Net 2.0 intranet site. At the very top of our main page I provide a TextBox and a Button for submitting Google searches....
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.