Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > Response.Redirect & Server.Execute

Reply
Thread Tools

Response.Redirect & Server.Execute

 
 
RN1
Guest
Posts: n/a
 
      12-17-2007
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.
 
Reply With Quote
 
 
 
 
Mike Brind
Guest
Posts: n/a
 
      12-17-2007

"RN1" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
 
 
 
Evertjan.
Guest
Posts: n/a
 
      12-17-2007
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)
 
Reply With Quote
 
Mike Brind
Guest
Posts: n/a
 
      12-17-2007

"Evertjan." <(E-Mail Removed)> wrote in message
news:Xns9A09D44AFA6B8eejj99@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.


 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      12-17-2007
Mike Brind wrote on 17 dec 2007 in
microsoft.public.inetserver.asp.general:

>
> "Evertjan." <(E-Mail Removed)> wrote in message
> news:Xns9A09D44AFA6B8eejj99@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)
 
Reply With Quote
 
RN1
Guest
Posts: n/a
 
      12-18-2007
On Dec 18, 12:52 am, "Evertjan." <(E-Mail Removed)>
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?
 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      12-18-2007
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)
 
Reply With Quote
 
Anthony Jones
Guest
Posts: n/a
 
      12-22-2007
"Evertjan." <(E-Mail Removed)> wrote in message
news:Xns9A09F2572B8D7eejj99@194.109.133.242...
> Mike Brind wrote on 17 dec 2007 in
> microsoft.public.inetserver.asp.general:
>
> >
> > "Evertjan." <(E-Mail Removed)> wrote in message
> > news:Xns9A09D44AFA6B8eejj99@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


 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      12-22-2007
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)
 
Reply With Quote
 
Anthony Jones
Guest
Posts: n/a
 
      12-26-2007
"Evertjan." <(E-Mail Removed)> wrote in message
news:Xns9A0EA99627B99eejj99@194.109.133.242...
> 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?
>


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_EnableRedirec ts) = 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


--
Anthony Jones - MVP ASP/ASP.NET


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments