Cookie Over Write

[Scott]

if i create a cookie named myCompany and store several values like userLast
and userFirst and then later want to add a new name-pair such as
userPreference1, can i append the new name-pair without re-writing the
userLast and userFirst name-pairs?

In other words, does a new name-pair to the same cookie over write other
existing keys?

CODE:
Response.Cookies("myCompany")("userLast") = Session("userLast")
Response.Cookies("myCompany")("userFirst") = Session("userFirst")

CODE 2:
Response.Cookies("myCompany")("userPreference1") =
Session("userPreference1")

 

[Kyle Peterson]

I am pretty sure every time you change any Key in the cookie you have to
rewrite them all or you will lose the key you don't set.
It is just the way they work.

 

[Evertjan.]

Kyle Peterson wrote on 04 jan 2006 in
microsoft.public.inetserver.asp.general:

I am pretty sure every time you change any Key in the cookie you have
to rewrite them all or you will lose the key you don't set.
It is just the way they work.

Not true.
But why ask?
Such things are so easy to test:

========== test1.asp ==========

<%
Response.Cookies("myCompany")("1") = "x1"
Response.Cookies("myCompany")("2") = "x2"
%>
<a href ='test2.asp'>go to test2.asp</a>

========== test2.asp ==========

<%
Response.Cookies("myCompany")("3") = "x3"
%>

<br><%=Request.Cookies("myCompany")("1")%>
<br><%=Request.Cookies("myCompany")("2")%>
<br><%=Request.Cookies("myCompany")("3")%>

========= test2.asp shows:

x1
x2
x3

 

[scott]

thanks.

Kyle Peterson wrote on 04 jan 2006 in
microsoft.public.inetserver.asp.general:

Not true.
But why ask?
Such things are so easy to test:

========== test1.asp ==========

<%
Response.Cookies("myCompany")("1") = "x1"
Response.Cookies("myCompany")("2") = "x2"
%>
<a href ='test2.asp'>go to test2.asp</a>

========== test2.asp ==========

<%
Response.Cookies("myCompany")("3") = "x3"
%>

<br><%=Request.Cookies("myCompany")("1")%>
<br><%=Request.Cookies("myCompany")("2")%>
<br><%=Request.Cookies("myCompany")("3")%>

========= test2.asp shows:

x1
x2
x3

 

[Kyle Peterson]

Evertjan is correct. My Bad.
Not sure why I thought that but I could swear I encountered that or read
that it did that in the past.

 

[Dave Anderson]

Not true.

More like "partially true". If you write them from the client side, they all
get overwritten.



--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 04 jan 2006 in
microsoft.public.inetserver.asp.general:

More like "partially true". If you write them from the client side,
they all get overwritten.

Why would you, if you have ASP?

;-}

 

[Dave Anderson]

Why would you, if you have ASP?

Indeed, ASP renders moot any and all client-side scripting. Anything that
can be done with DHTML can also be done with one or more round-trips.

Or not.


--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 04 jan 2006 in
microsoft.public.inetserver.asp.general:

Indeed, ASP renders moot any and all client-side scripting. Anything
that can be done with DHTML can also be done with one or more
round-trips.

Or not.

Without your "round trip",
there is no reason for manipulating a cookie.

And I prefer the clientside code independence of ASP.

 

[Dave Anderson]

Without your "round trip",
there is no reason for manipulating a cookie.

Without a further request, perhaps, but cookies can be useful for a host of
reasons (like state memory), and I see no reason why a round-trip should be
mandated for simply setting a cookie.

And I prefer the clientside code independence of ASP.

As do I. But like every tool in the bag, client-side scripting has its uses.
And occasionally it is appropriate for writing cookies.



--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 05 jan 2006 in
microsoft.public.inetserver.asp.general:

Without a further request, perhaps, but cookies can be useful for a
host of reasons (like state memory), and I see no reason why a
round-trip should be mandated for simply setting a cookie.

That is not necessary as the "round trip" can wait till necessary anyway.

 

[Dave Anderson]

That is not necessary as the "round trip" can wait till necessary
anyway.

You mean setting the cookie? That response assumes the round-trip is the
next destination for the browser. What if the user just wants to do
something else with the browser and then return to your page later?
Opportunity lost.



--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Evertjan.]

Dave Anderson wrote on 05 jan 2006 in
microsoft.public.inetserver.asp.general:

You mean setting the cookie? That response assumes the round-trip is the
next destination for the browser. What if the user just wants to do
something else with the browser and then return to your page later?
Opportunity lost.

True.

I still think in a aspable environment, one should not demean oneself
to a clientside construct. Usually there is a way around that.

 

[Dave Anderson]

I still think in a aspable environment, one should not demean
oneself to a clientside construct. Usually there is a way
around that.

I don't quite see it that way. I think the server-side approach is better,
most of the time. But I am not fond of ironclad rules -- those that use
words like ALWAYS or NEVER. Here is one I NEVER break: ALWAYS assume the
client can manipulate any part of the request.

With that in mind, I generally treat client-side scripting as a tool to make
the experience more convenient for the user. If the OP had that purpose in
mind and chose to tweak some cookies on the client-side, and those cookies
have keys, then he must dispose of each key-value pair, not just the one
being changed. Your opinion does not change that fact.



--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.