By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,538 Members | 2,225 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,538 IT Pros & Developers. It's quick & easy.

Response.Redirect & Server.Execute

P: n/a
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
Share this Question
Share on Google+
9 Replies


P: n/a

"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

P: n/a
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

P: n/a

"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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
"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

P: n/a
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

P: n/a
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 discussion thread is closed

Replies have been disabled for this discussion.