Javascript can't delete server created cookie with no domain?

[Wysiwyg]

After a server created cookie is processed on the client I want it removed,
cleared, or expired in the javascript block but have been unable to do this.

If I set a cookie value in the server code behind and don't use a domain
then I can not change or remove that cookie's value on the client. If I
subsequently create the cookie again in the codebehind then I actually end
up with TWO cookies with the same name in the response. The cookie created
can be read at it's original server created value but I can't change it on
the client side.

This isn't a problem if an actual domain value is present, the cookie can be
removed or changed as I'd expect, but that isn't practical or desired to use
a domain in this case. A client session will only see the cookie that has a
domain if 1) the domain has at least one period in it and 2) the host
address of the session ends with whatever is in the domain value. That means
"localhost" isn't a valid value for the domain which makes it a pain for
development.

I create the cookie on the server like so...

HttpCookie cookie = new HttpCookie("CookieNameHere",strValue);
Response.Cookies.Add(cookie);

I attempt to delete it on the client in Javascript with a statement like
this:

document.cookie = 'CookieNameHere=';

I've also tried variations that specify the domain= and expires= values with
no difference.

When I look at the actual cookies in the Visual Studio debug by adding the
cookie object in the watch list I see the System.Web.HttpCookie object with
two sets of values. The usual properties for name, path, domain,
stringValue, etc. are there twice. One set has a _ prefix for each property,
i.e. _domain. The "_domain" is set to null but the "domain" property is an
empty string. Changes in the client javascript code affect the _ prefixed
values, so _stringValue is correctly cleared, but the original server set
stringValue (with no prefix) is untouched and is actually used if the cookie
is read on the client side in the future. If I use an actual domain for the
cookie then the two values are the same.

After the javascript statement which is meant to clear the cookie I see two
cookie values in the Visual Studio debugger. One with a null _stringValue
and a null _domain and one with the original string value and a domain = ''.
If the value of the cookie is subsequently checked the original value is
still there and is used.

I've even tried deleting the request and/or response cookie after the
initial render of the page where the cookie is used but that doesn't, and
isn't supposed to, affect the client cookie anyway.

Setting cookie.Domain = string.empty in the code behind doesn't change
anything and setting cookie.Domain = null in the code behind doesn't do
anything different either.

Has anyone run into this problem before? Is there some way I haven't
mentioned to clear a cookie? Is there a workaround known?

Thanks for any help!
Bill

 

[Wysiwyg]

Nevermind... Even though the debugger showed the path as "/" when I looked
at it what the client was actually doing when I tried to delete the cookie
is prepending the cookie name without the "=" sign i.e. "CookieNameHere;
NextCookie=value; CookieNameHere=oldvalue" instead of setting the value to
"NextCookie=value;CookieNameHere". If I explicitly add a path to the
javascript statement,i.e.

document.cookie = 'CookieNameHere=; path=/';

....then the correct cookie value is removed correctly. I'd think the path
should be redundant since as far as the server was concerned (judging from
the debugger) that was the cookie's path anyway.

 

[bruce barker]

the browser will not send back a cookie without a domain name.you do not
need a dot in the domain name to use for a cookie so you can use localhost
for a cookie without any trouble. but to use a domain suffix (tail) match
you need at least 2 dots (or 3 if not in the standard 7 set - .net, .com,
....) most browsers want the leading dot to enable tail match.

will not tail match
localhost
com
.com
.net
.va.us (requires 3 dots)

will tail match

mysite.com
.mysite.com (will work with www.mysite.com, mysite.com,
secure.mysite.com, etc)
.main.va.us

-- bruce (sqlwork.com)


| After a server created cookie is processed on the client I want it
removed,
| cleared, or expired in the javascript block but have been unable to do
this.
|
| If I set a cookie value in the server code behind and don't use a domain
| then I can not change or remove that cookie's value on the client. If I
| subsequently create the cookie again in the codebehind then I actually end
| up with TWO cookies with the same name in the response. The cookie created
| can be read at it's original server created value but I can't change it on
| the client side.
|
| This isn't a problem if an actual domain value is present, the cookie can
be
| removed or changed as I'd expect, but that isn't practical or desired to
use
| a domain in this case. A client session will only see the cookie that has
a
| domain if 1) the domain has at least one period in it and 2) the host
| address of the session ends with whatever is in the domain value. That
means
| "localhost" isn't a valid value for the domain which makes it a pain for
| development.
|
| I create the cookie on the server like so...
|
| HttpCookie cookie = new HttpCookie("CookieNameHere",strValue);
| Response.Cookies.Add(cookie);
|
| I attempt to delete it on the client in Javascript with a statement like
| this:
|
| document.cookie = 'CookieNameHere=';
|
| I've also tried variations that specify the domain= and expires= values
with
| no difference.
|
| When I look at the actual cookies in the Visual Studio debug by adding the
| cookie object in the watch list I see the System.Web.HttpCookie object
with
| two sets of values. The usual properties for name, path, domain,
| stringValue, etc. are there twice. One set has a _ prefix for each
property,
| i.e. _domain. The "_domain" is set to null but the "domain" property is an
| empty string. Changes in the client javascript code affect the _ prefixed
| values, so _stringValue is correctly cleared, but the original server set
| stringValue (with no prefix) is untouched and is actually used if the
cookie
| is read on the client side in the future. If I use an actual domain for
the
| cookie then the two values are the same.
|
| After the javascript statement which is meant to clear the cookie I see
two
| cookie values in the Visual Studio debugger. One with a null _stringValue
| and a null _domain and one with the original string value and a domain =
''.
| If the value of the cookie is subsequently checked the original value is
| still there and is used.
|
| I've even tried deleting the request and/or response cookie after the
| initial render of the page where the cookie is used but that doesn't, and
| isn't supposed to, affect the client cookie anyway.
|
| Setting cookie.Domain = string.empty in the code behind doesn't change
| anything and setting cookie.Domain = null in the code behind doesn't do
| anything different either.
|
| Has anyone run into this problem before? Is there some way I haven't
| mentioned to clear a cookie? Is there a workaround known?
|
| Thanks for any help!
| Bill
|
|

 

[Wysiwyg]

When I created the cookie on the server codebehind I tried setting
cookie.Domain to to the hostname, localhost in my case, and the cookie
values didn't show up in my document.cookies string on the client side. I
could create and access a localhost domain cookie value on the server side,
sure, but the client didn't see it.

It seems the whole domain issue was a red herring anyway. The whole null vs
empty string thing isn't reflected in the client side headers anyway. I
think the server created the cookie with a path of "/" by default, and the
debugger reported it as such, but the client didn't consider that the
current path. If I explicitly set path in the client javascript's cookie
code then my problem was solved. It just didn't register with me at first
that the debugger said the cookies had a path of "/" while that wasn't
actually the client's current path even though it was reading the cookie ok.