Greetings!

I would like to use Server.Transfer to redirect users to a given page,
while maintaining the state of form fields. This works fine on a single
server.

However, this will be deployed in a load balanced environment. I know
that Session variables and load balanced environments don't mix. Do I
have a cause for concern with Server.Transfer as well?

Thanks in advance.


Chris

Re: Server.Transfer and Load Balanced Environments by Anthony

Anthony
Fri Sep 08 02:29:45 CDT 2006


"Chris Bellini" <chris-hatesspam@spam.chrisbellini.blows.com> wrote in
message news:eHA$NHu0GHA.2356@TK2MSFTNGP03.phx.gbl...
> Greetings!
>
> I would like to use Server.Transfer to redirect users to a given page,
> while maintaining the state of form fields. This works fine on a single
> server.
>
> However, this will be deployed in a load balanced environment. I know
> that Session variables and load balanced environments don't mix. Do I
> have a cause for concern with Server.Transfer as well?
>
> Thanks in advance.
>
>
> Chris

Server transfer will not transfer the request to another server even in a
load balanced system.



Re: Server.Transfer and Load Balanced Environments by Aaron

Aaron
Fri Sep 08 14:27:25 CDT 2006

I haven't done extensive testing of this, but I am fairly certain that both
server.transfer and server.execute will stay on the same server. At least
that's the theory ... I'll repeat that I haven't done any thorough testing
of this. As with most things, if you have concerns it shouldn't take much
to set up a test.

A




"Chris Bellini" <chris-hatesspam@spam.chrisbellini.blows.com> wrote in
message news:eHA$NHu0GHA.2356@TK2MSFTNGP03.phx.gbl...
> Greetings!
>
> I would like to use Server.Transfer to redirect users to a given page,
> while maintaining the state of form fields. This works fine on a single
> server.
>
> However, this will be deployed in a load balanced environment. I know
> that Session variables and load balanced environments don't mix. Do I
> have a cause for concern with Server.Transfer as well?
>
> Thanks in advance.
>
>
> Chris



Re: Server.Transfer and Load Balanced Environments by Dave

Dave
Fri Sep 08 15:26:59 CDT 2006

Aaron Bertrand [SQL Server MVP] wrote:
> I haven't done extensive testing of this, but I am fairly
> certain that both server.transfer and server.execute will
> stay on the same server. At least that's the theory ...

They HAVE TO stay on the same server. They share a response stream (unlike
Response.Redirect, which tells the browser to send a new request, and
subsequently does not share a response stream with the original request).



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.



Re: Server.Transfer and Load Balanced Environments by Aaron

Aaron
Fri Sep 08 15:40:51 CDT 2006

> They HAVE TO stay on the same server. They share a response stream (unlike
> Response.Redirect, which tells the browser to send a new request, and
> subsequently does not share a response stream with the original request).

Right, after I posted I thought about it a bit more, and of course
server.transfer/execute would not possibly be able to send anything back out
to the load balancer, because by definition they stay local.



Re: Server.Transfer and Load Balanced Environments by Chris

Chris
Fri Sep 08 20:36:20 CDT 2006

Aaron Bertrand [SQL Server MVP] wrote:
>> They HAVE TO stay on the same server. They share a response stream (unlike
>> Response.Redirect, which tells the browser to send a new request, and
>> subsequently does not share a response stream with the original request).
>
> Right, after I posted I thought about it a bit more, and of course
> server.transfer/execute would not possibly be able to send anything back out
> to the load balancer, because by definition they stay local.
>
>
So it's safe to say that shouldn't run into any issues of having
hidden form fields disappear on me after a call to Server.Transfer?


Chris

Re: Server.Transfer and Load Balanced Environments by Dave

Dave
Sat Sep 09 09:26:06 CDT 2006

Chris Bellini wrote:
> So it's safe to say that shouldn't run into any issues of
> having hidden form fields disappear on me after a call to
> Server.Transfer?

Hidden form fields are a client-side issue. The server only knows requests.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.



Re: Server.Transfer and Load Balanced Environments by Anthony

Anthony
Sun Sep 10 01:28:56 CDT 2006


"Chris Bellini" <chris-hatesspam@spam.chrisbellini.blows.com> wrote in
message news:u3RFlC70GHA.1568@TK2MSFTNGP03.phx.gbl...
> Aaron Bertrand [SQL Server MVP] wrote:
> >> They HAVE TO stay on the same server. They share a response stream
(unlike
> >> Response.Redirect, which tells the browser to send a new request, and
> >> subsequently does not share a response stream with the original
request).
> >
> > Right, after I posted I thought about it a bit more, and of course
> > server.transfer/execute would not possibly be able to send anything back
out
> > to the load balancer, because by definition they stay local.
> >
> >
> So it's safe to say that shouldn't run into any issues of having
> hidden form fields disappear on me after a call to Server.Transfer?
>

No you shouldn't. All form fields will appear to the transfered to page the
same as they would have to the original target.

>
> Chris



Re: Server.Transfer and Load Balanced Environments by Chris

Chris
Sun Sep 10 12:46:54 CDT 2006

Anthony Jones wrote:
> No you shouldn't. All form fields will appear to the transfered to page the
> same as they would have to the original target.
>
>> Chris
>
>

Phew, that's good to hear :) Thanks.


Chris

Re: Server.Transfer and Load Balanced Environments by Dave

Dave
Mon Sep 11 11:20:17 CDT 2006

Anthony Jones wrote:
>> So it's safe to say that shouldn't run into any issues of
>> having hidden form fields disappear on me after a call to
>> Server.Transfer?
>
> No you shouldn't. All form fields will appear to the
> transfered to page the same as they would have to the
> original target.

That's not technically correct. The two scripts share Request and Response
objects, which are server-side, while form fields (hidden or otherwise) are
client-side constructs.

The conclusion is correct, however. There should be no loss of Request
elements in the transfer from one script to another.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.



Re: Server.Transfer and Load Balanced Environments by Anthony

Anthony
Mon Sep 11 11:34:01 CDT 2006


"Dave Anderson" <NYRUMTPELVWH@spammotel.com> wrote in message
news:uIDJt4b1GHA.4748@TK2MSFTNGP04.phx.gbl...
> Anthony Jones wrote:
> >> So it's safe to say that shouldn't run into any issues of
> >> having hidden form fields disappear on me after a call to
> >> Server.Transfer?
> >
> > No you shouldn't. All form fields will appear to the
> > transfered to page the same as they would have to the
> > original target.
>
> That's not technically correct. The two scripts share Request and Response
> objects, which are server-side, while form fields (hidden or otherwise)
are
> client-side constructs.
>

What is Request.Form("MyHiddenField") ??
ASP is aware of Form fields, it is not, from an ASP point of view, purely a
'client side construct' even though it is from a HTTP point of view. Do we
have to keep doing this Dave??

> The conclusion is correct, however. There should be no loss of Request
> elements in the transfer from one script to another.
>
>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message.
Use
> of this email address implies consent to these terms.
>
>



Re: Server.Transfer and Load Balanced Environments by Dave

Dave
Mon Sep 11 11:45:33 CDT 2006

Anthony Jones wrote:
>> That's not technically correct. The two scripts share Request and
>> Response objects, which are server-side, while form fields (hidden
>> or otherwise) are client-side constructs.
>
> What is Request.Form("MyHiddenField") ??

It is an element of the [Form] collection of a Request. There is no
requirement that it be associated with a field, which I can easily
demonstrate with an XMLHttpRequest object. Or the Gecko extension
LiveHTTPHeaders, for that matter.



> ASP is aware of Form fields, it is not, from an ASP point of view,
> purely a 'client side construct' even though it is from a HTTP
> point of view.

I wholeheartedly disagree. The only thing ASP knows about the client is what
the client tells it -- the content of the Request.



> Do we have to keep doing this Dave??

No.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.



Re: Server.Transfer and Load Balanced Environments by Anthony

Anthony
Mon Sep 11 16:14:04 CDT 2006


"Dave Anderson" <NYRUMTPELVWH@spammotel.com> wrote in message
news:ezIc0Gc1GHA.4748@TK2MSFTNGP04.phx.gbl...
> Anthony Jones wrote:
> >> That's not technically correct. The two scripts share Request and
> >> Response objects, which are server-side, while form fields (hidden
> >> or otherwise) are client-side constructs.
> >
> > What is Request.Form("MyHiddenField") ??
>
> It is an element of the [Form] collection of a Request.

If you were to give that a single word label what would it be?

No let me guess anything that but 'Field' right?


>There is no
> requirement that it be associated with a field, which I can easily
> demonstrate with an XMLHttpRequest object. Or the Gecko extension
> LiveHTTPHeaders, for that matter.
>

Some might call that emulation ;)

>
>
> > ASP is aware of Form fields, it is not, from an ASP point of view,
> > purely a 'client side construct' even though it is from a HTTP
> > point of view.
>
> I wholeheartedly disagree. The only thing ASP knows about the client is
what
> the client tells it -- the content of the Request.
>

ASP doesn't care about the client but it does support the 'concept' of a
Form which has fields. How the client may or may not represent it isn't
it's business but to say tha ASP doesn't have 'Form field constructs' is odd
to say the least when it clearly exposes a collection of values (which I
would call fields) in property called Form is bit like saying black is
white.



>
>
> > Do we have to keep doing this Dave??
>
> No.
>

Yet we end up doing it anyway. Daft but fun.

>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message.
Use
> of this email address implies consent to these terms.
>
>



Re: Server.Transfer and Load Balanced Environments by Dave

Dave
Mon Sep 11 17:40:55 CDT 2006

Anthony Jones wrote:
>> It is an element of the [Form] collection of a Request.
>
> If you were to give that a single word label what would it be?

I already gave one: element. The only other one I would consider is item**,
but that has special meaning in this case, since the element is an object
with properties .Count, and .Item (Item is the default property).



> No let me guess anything that but 'Field' right?

Wrong. See above.



>> There is no requirement that it be associated with a field,
>> which I can easily demonstrate with an XMLHttpRequest object.
>> Or the Gecko extension LiveHTTPHeaders, for that matter.
>
> Some might call that emulation ;)

I call it constructing a request, which is nothing more than a message.



> ASP doesn't care about the client but it does support the
> 'concept' of a Form which has fields.

I would agree that HTML supports that concept, but not ASP.



> How the client may or may not represent it isn't it's business...

The client renders the HTML and creates Requests. So if there is a question
of how the client represents something, that should center on the Response
(which creates the HTML), and not on the Request.

You have it exactly backward. The client creates the request, parts of which
ASP assembles into a Request Object and its Form Collection for exposure to
the script. The ASP script creates a Response message, which usually
contains a status of 200, a content-type of text/html, and a text string
representing an HTML document, among other things. The browser chooses how
to represent that HTML document fragment of the response. There is no
"concept of a form" in that response outside the HTML.



> but to say tha ASP doesn't have 'Form field constructs' is odd to
> say the least when it clearly exposes a collection of values
> (which I would call fields) in property called Form is bit like
> saying black is white.

It only looks like a "collection of values" to a VBScripter. Those of us who
write ASP in JScript know the truth: Request.Form is a collection of
objects. Admittedly, that fact alone does not make it any more or any less
like a collection of *fields*. But neither does the fact that ASP names the
collection "Form".

Consider this JScript illustration of your argument:

var black = {Count:1,Item:"black"}
if (black == "black") {
Response.Write(black + " is black")
} else {
Response.Write(black + " is white")
}

The output? [object Object] is white.




** I would use item because the JScript Enumerator object exposes them via
.item().
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.