Response.Redirect & Server.Execute

Discussion in 'ASP General' started by RN1, Dec 17, 2007.

  1. RN1

    RN1 Guest

    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.
     
    RN1, Dec 17, 2007
    #1
    1. Advertising

  2. RN1

    Mike Brind Guest

    "RN1" <> wrote in message
    news:...
    > 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
     
    Mike Brind, Dec 17, 2007
    #2
    1. Advertising

  3. RN1

    Evertjan. Guest

    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)
     
    Evertjan., Dec 17, 2007
    #3
  4. RN1

    Mike Brind Guest

    "Evertjan." <> 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.
     
    Mike Brind, Dec 17, 2007
    #4
  5. RN1

    Evertjan. Guest

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

    >
    > "Evertjan." <> 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)
     
    Evertjan., Dec 17, 2007
    #5
  6. RN1

    RN1 Guest

    On Dec 18, 12:52 am, "Evertjan." <>
    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?
     
    RN1, Dec 18, 2007
    #6
  7. RN1

    Evertjan. Guest

    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)
     
    Evertjan., Dec 18, 2007
    #7
  8. "Evertjan." <> wrote in message
    news:Xns9A09F2572B8D7eejj99@194.109.133.242...
    > Mike Brind wrote on 17 dec 2007 in
    > microsoft.public.inetserver.asp.general:
    >
    > >
    > > "Evertjan." <> 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
     
    Anthony Jones, Dec 22, 2007
    #8
  9. RN1

    Evertjan. Guest

    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)
     
    Evertjan., Dec 22, 2007
    #9
  10. "Evertjan." <> 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_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


    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Dec 26, 2007
    #10
  11. RN1

    Evertjan. Guest

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

    > "Evertjan." <> 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_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].

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Dec 26, 2007
    #11
  12. "Evertjan." <> wrote in message
    news:Xns9A12D8DE2279Aeejj99@194.109.133.242...
    > Anthony Jones wrote on 26 dec 2007 in
    > microsoft.public.inetserver.asp.general:
    >
    > > "Evertjan." <> 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_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.


    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Dec 26, 2007
    #12
  13. RN1

    Evertjan. Guest

    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)
     
    Evertjan., Dec 27, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    2
    Views:
    8,049
    Charles A. Lackman
    Jan 11, 2006
  2. =?Utf-8?B?VHJveQ==?=

    Response.redirect does not redirect from .aspx page

    =?Utf-8?B?VHJveQ==?=, Oct 18, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    5,304
    Srowe1975
    Oct 15, 2008
  3. Sal
    Replies:
    1
    Views:
    842
  4. David C. Holley

    server.execute/response.redirect/server.transfer

    David C. Holley, Jan 17, 2004, in forum: ASP General
    Replies:
    6
    Views:
    443
    David Holley
    Jan 18, 2004
  5. Ron Howard
    Replies:
    2
    Views:
    546
    Ron Howard
    Aug 11, 2004
Loading...

Share This Page