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.

 

[Mike Brind]

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.

 

[Evertjan.]

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.

 

[Mike Brind]

Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:


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.

 

[Evertjan.]

Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:

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.

 

[RN1]

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.

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?

 

[Evertjan.]

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.

 

[Anthony Jones]

Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:

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.

 

[Evertjan.]

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?

 

[Anthony Jones]

Anthony Jones wrote on 22 dec 2007 in
microsoft.public.inetserver.asp.general:


Can you give a coded example?

Actually what I said isn't entirely accurate. Neither XMLHTTP nor
ServerXMLHTTP gives you any choice, it will always automatically follow a
302 redirect.

Its the WinHTTP stack that underlies the ServerXMLHTTP that allows you to
disable redirects and it was that I was thinking of:-

Dim oWinHTTP
Dim oXML
Const WinHttpRequestOption_EnableRedirects = 6

Set oWinHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
oWinHTTP.Option(WinHttpRequestOption_EnableRedirects) = False

oWinHTTP.Open "GET", "http://server/folder/page.asp", False
oWinHTTP.Send

If oWinHTTP.Status = 200 Then
Set oXML = CreateObject("MSXML2.DOMDocument.3.0")
oXML.load oWinHTTP.responseBody
MsgBox "XML is " & Len(oXML.xml) & " characters in length"
ElseIf oWinHTTP.Status = 302 Then
MsgBox "Server Attempted Redirect to: " & _
oWinHTTP.getResponseHeader("Location")
End If

 

[Evertjan.]

Anthony Jones wrote on 26 dec 2007 in
microsoft.public.inetserver.asp.general:

Actually what I said isn't entirely accurate. Neither XMLHTTP nor
ServerXMLHTTP gives you any choice, it will always automatically follow a
302 redirect.

Its the WinHTTP stack that underlies the ServerXMLHTTP that allows you to
disable redirects and it was that I was thinking of:-

Dim oWinHTTP
Dim oXML
Const WinHttpRequestOption_EnableRedirects = 6

Set oWinHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
oWinHTTP.Option(WinHttpRequestOption_EnableRedirects) = False

oWinHTTP.Open "GET", "http://server/folder/page.asp", False
oWinHTTP.Send

If oWinHTTP.Status = 200 Then
Set oXML = CreateObject("MSXML2.DOMDocument.3.0")
oXML.load oWinHTTP.responseBody
MsgBox "XML is " & Len(oXML.xml) & " characters in length"
ElseIf oWinHTTP.Status = 302 Then
MsgBox "Server Attempted Redirect to: " & _
oWinHTTP.getResponseHeader("Location")
End If

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].

 

[Anthony Jones]

Anthony Jones wrote on 26 dec 2007 in
microsoft.public.inetserver.asp.general:

Actually what I said isn't entirely accurate. Neither XMLHTTP nor
ServerXMLHTTP gives you any choice, it will always automatically follow a
302 redirect.

Its the WinHTTP stack that underlies the ServerXMLHTTP that allows you to
disable redirects and it was that I was thinking of:-

Dim oWinHTTP
Dim oXML
Const WinHttpRequestOption_EnableRedirects = 6

Set oWinHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
oWinHTTP.Option(WinHttpRequestOption_EnableRedirects) = False

oWinHTTP.Open "GET", "http://server/folder/page.asp", False
oWinHTTP.Send

If oWinHTTP.Status = 200 Then
Set oXML = CreateObject("MSXML2.DOMDocument.3.0")
oXML.load oWinHTTP.responseBody
MsgBox "XML is " & Len(oXML.xml) & " characters in length"
ElseIf oWinHTTP.Status = 302 Then
MsgBox "Server Attempted Redirect to: " & _
oWinHTTP.getResponseHeader("Location")
End If

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.

 

[Evertjan.]

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.