Closed Bug 28956 Opened 20 years ago Closed 20 years ago

cookie reading/setting bug in Mozilla5 and all Netscape browsers. Works in IE4+ and Opera

Categories

(Core :: Networking: Cookies, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jrspm, Assigned: morse)

References

()

Details

I posted this question to:

netscape.public.general
netscape.public.mozilla.layout
netscape.public.mozilla.netlib

I have not recieved any real answer from anyone at Netscape.  I read all about 
bug 8743 in bugzilla.  I am wondering what my best approach is to deal with the 
following problem:



I am having difficulty with Netscape cookies as opposed to IE4+ and
Opera 3.6

The issue is this.

I have a site where it can be called up using
http://thedomainname.com   OR  http://www.thedomainname.com

If I set a cookie and don't specify the domain name, a cookie get
written  thedomainname.com   OR  www.thedomainname.com

If it was set to www.thedomainname.com, when the same user goes back
to the site, but type  thedomainname.com  without the preceding "www",
the cookie cannot be read.  Also, if the user set the original cookie
under  http://thedomainname.com  and I didn't specify the Path
attribute,   www.thedomainname.com will NOT be able to read the
cookie.

The other thing to note here is that if the URL is
http://thedomainname.com , netscape will write the cookie like this:  

thedomainname.com	FALSE	/ FALSE	2137622390	USER
1285698

Notice that this is Illegal according to the cookie spec which
REQUIRES at least 2 dots in top level domains.  In this case, it only
has the one.

But, if I set the domain attribute to   .thedomainname.com  only
www.thedomainname.com will be able to read it (but only when I specify the Path 
attribute to something like "/").  Since
http://thedomainname.com does not have a dot in front of
"thedomainname", it doesn't recognize it.


One solution would be to set the domain attribute to
"thedoomainname.com" without the preceding dot.  However, this is
impossible for me to do because I am using Cold Fusion's <cfcookie>
tag to set the cookie.  The domain attribute in <cfcookie> REQUIRES
that a dot precede whatever domain name you are putting in there.
Also, because I can't do that, I can't set the Path attribute because
<cfcookie> REQUIRES that the domain attribute is present when setting
the Path attribute.


One thing I noticed is that on Netscape.com, you set cookies as
".netscape.com".  Can you tell me how this cookie is read when the URL
is "http://netscape.com" since it doesn't have the dot preceding
netscape.com????


The thing is, In ANY other browser, I can set the cookie with a domain
attribute of   .thedomainname.com  and it will be read under both
http://thedomainname.com AND  http://www.thedomainname.com without
problem.  Netscape sets the cookie momentarily, but then clicking on
any other link in the site, the cookie disappears from memory.  I have
verified this in Netscape 3.04, 4.08, 4.7, 4.71 (unofficial version),
AND Mozilla 5.0


Is this a bug in your browsers or is everyone else doing wrong???  Is
there anything that I'm missing???  Any suggestions????

Thanks for your time.


Jake


Here is a response I got from Erik van der Poel:

> One thing I noticed is that on Netscape.com, you set cookies as
> ".netscape.com".  Can you tell me how this cookie is read when the URL
> is "http://netscape.com" since it doesn't have the dot preceding
> netscape.com????

This sounds like a bug in netscape.com. It ought to return an HTTP
redirect, so that the browser will fetch a document from a "real" host
such as home.netscape.com (which does have 2 dots in the name). You will
notice that it *does* redirect to my.netscape.com if you go to the My
Netscape thing (the icon that looks like a person's head), so cookies
*do* work there.

> The thing is, In ANY other browser, I can set the cookie with a domain
> attribute of   .thedomainname.com  and it will be read under both
> http://thedomainname.com AND  http://www.thedomainname.com without
> problem.  Netscape sets the cookie momentarily, but then clicking on
> any other link in the site, the cookie disappears from memory.  I have
> verified this in Netscape 3.04, 4.08, 4.7, 4.71 (unofficial version),
> AND Mozilla 5.0

This sounds like a bug in the old Netscape browsers and the new Mozilla.
I'm Cc'ing the netlib folks. Necko folks, please file a bug. Even if the
spec says something about 2 dots, both MSIE and Opera can handle cookie
domains like .netscape.com even if the host is only netscape.com, so
Mozilla ought to support that too. Here is the original message:

  news://news.mozilla.org/zO6yOAHPK7bK243JMrcSAfSLkImf%404ax.com

Erik




So, what can I do about this???  If I set the domain name to ".domain.com" and 
the user goes to "domain.com", Netscape (all versions including the latest 
build of Mozilla5), the cookie is not able to be read.  Also, ".domain.com" 
cookie is not able to be read by "www.domain.com" if the Path attribute is not 
set to something like "/".  This in not a problem in IE4+ and Opera 3.6 (only 
version of Opera tested).  They can read a cookie set at ".domain.com" withing 
both domain.com and www.domain.com

So, if I set the legal cookie of ".domain.com", I am in compliance with the 
cookie spec and can support IE4+ and Opera users, but I will leave Netscape 
users out to dry.  The only way for netscape users to read the cookie if I set 
it to ".domain.com" is if I set the path attribute to "/" AND they go 
to "www.domain.com".  If they go to "domain.com" they will be utterly confused 
becasue the cookie will not be set or read from that URL.

What is my best approach for fixing this problem?????

thanks,

Jake
You probably know this already, but let me state it just in case it clears up 
any confusion.  There are two types of cookies -- host cookies and domain 
cookies.  They are differentiated by have a "domain=" attribute in the 
set-cookie header.

You have two different hosts.  If you set a host cookie from one of those hosts 
it will not be able to be read by the other.  That explains part of the symptoms 
you were describing.

The cookies.txt file has an is-domain field specifying if the cookie is a host 
or domain cookie.  The examples you showed have a "false" in that field 
indicating that you indeed have host cookies.

The first field of the cookies.txt field specifies the host for a host cookie or 
the domain for a domain cookie.  Since you have host cookies, the entry you are 
seeing is the host and that is why it does not start with a dot.  (Of course 
sites can erroneously set a domain cookie with a domain value not starting with 
a dot.  That is an error on the part of the site but we need to support that as 
described in bug 8743 -- otherwise we break yahoo mail.)

Then you spoke about setting the domain attribute to .thedomain.com.  In that 
case you will be getting a domain cookie.  But only your www.thedomain.com site 
is in that domain so only it will get those cookies.  This is expected behavior.  
And then you mentioned trying to set it to thedomain.com (without the leading 
dot).  Unfortunately we catch that error and interpret it as if there were a 
leading dot (the yahoo mail problem) so that won't change anything.

With that explaination in mind, let me know if you think there is still a 
problem.  Be specific as to what problem you think still exists because you 
spoke about many things in this report.

Closing this out as invalid for now but feel free to reopen it if you still 
think there is a specific problem.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I was not quite aware of the difference between host and domain cookies.  
Before reading your comments.  I had an implicit idea about them because 
setting the Domain and Path attributes made Netscape treat the cookies 
differently, so I knew there was some difference, just didn't know what it was.

You mentioned this:
"And then you mentioned trying to set it to thedomain.com (without the leading 
dot).  Unfortunately we catch that error and interpret it as if there were a 
leading dot (the yahoo mail problem) so that won't change anything."

Does this mean that you will stop interpreting "thedomain.com" as if it had a 
leading dot to fix the yahoo mail problem???


Beyond that, I still think there is a real problem.  Let's say that Netscape's 
implementation of cookies is right on and works to the spec (whether that is 
true or not).  The problem with this is that other browsers such as IE4+ and 
Opera are more liberal with how they treat cookies.  For instance...

If I set a cookie in IE4+ or Opera as ".thedomain.com", even without specifying 
the Domain or Path attributes, both IE4+ AND Opera read this cookie whether the 
user is at http://thedomain.com  OR  http://www.thedomain.com

That might be against the cookie spec, I'm not sure, but that is what happens 
with both of those browsers.  Netscape and Mozilla5 (currently), on the other 
hand, will only read said cookie under these specific conditions:

1. the URL is = http://www.thedomain.com
2. the Domain AND Path attributes have been specified

The specific problem I have is that I tried doing the following in Cold Fusion 
to set a cookie:

<cfcookie name="testcookie" expires="NEVER" value="1" domain=".thedomain.com" 
path="/">

Both IE4+ AND Opera were able to read this under: http://thedomain.com AND 
http://www.thedomain.com

But Netscape users were out of luck if they went to http://thedomain.com .  In 
that case, the cookie could not be read at all.  This was VERY confusing to 
users AND to me (trying to figure out why IE4+ and Opera worked, but Netscape 
didn't)

Now, this could have worked if I'd been able to do this:

<cfcookie name="testcookie" expires="NEVER" value="1" domain="thedomain.com" 
path="/">

Notice that in this case, I've set the Domain attribute without the preceding 
dot.  This would make it so Netscape would work the same as IE4+ and Opera, 
BUT, Cold Fusion (correctly) does not allow me to set the Domain attribute 
without a preceding dot, so running this tag throws and Cold Fusion error.

What I finally did to work around this was to have the web server catch URL's 
going to http://thedomain.com  and redirecting them to  http://www.thedomain.com

After doing that, I was able to set the cookie as in the first example and 
Netscape will work with it.

Why should I have to do this workaround when the two other major browsers (if 
you can call Opera major) are flexible and work for all cases.  Why should 
Netscape be stingy and have to be worked around???

One other issue is the following:...

What about setting cookies for a subdomain and having only the
subdomain being able to read the cookie.  For instance, lets say I
have the following situation:

domain = jake.com

I have a particular machine on a subdomain that I then give another
name to specify the particular site on that subdomain:

subdomain = newproject.dev.jake.com

dev = a way to distinguish the machine this subdomain is being used on
newproject = the site I am working on

I ONLY want newproject to be able to read the cookies, so I want to
set my cookie with the domain attribute being   

".newproject.dev.jake.com"

However, the Netscape cookie problem persists here.  Netscape won't
read the cookie because the URL:  http://newproject.dev.jake.com  does
not contain a dot ( "." ) in front of it. 

I could set the domain attribute to be "newproject.dev.jake.com"
without the dot to allow Netscape to do this, but if I try and set
this using Cold Fusion it will throw an error saying that domain
attributes in the <cfcookie> tag REQUIRE a dot preceding the domain
name.  So then I suppose I could just do this with Javascript, but why
should I have to????


I wrote the above issue in a reply to someone in a netscape newsgroup.  I now 
understand that I would just set a host cookie such 
as "newproject.dev.jake.com" in this case and not use the Domain or Path 
attributes so that Cold Fusion would not error out on this.

The previous argument still holds, though.  IE4+ AND Opera recognize the cookie 
when set under the Domain attribute of ".newproject.dev.jake.com".  I don't 
even need to set the Path attribute.  So again, Both IE4+ and Opera give me no 
trouble and basically let me do what I want to, whereas Netscape will not read 
the cookie under the domain ".newproject.dev.jake.com" when I go to  
http://newproject.dev.jake.com


So, do I have a valid point here???  

In short, IE4+ and Opera give me no problems, whereas Netscape gives me 
headaches whether or not Netscape is doing the "Right" thing and IE4+ and Opera 
are doing the "Wrong" thing.

Jake
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> Does this mean that you will stop interpreting "thedomain.com" as if it had
> a leading dot to fix the yahoo mail problem???

It means that we will interpret "domain=thedomain.com" in the set-cookie header 
as if it were "domain=.thedomain.com"

> Let's say that Netscape's implementation of cookies is right on and works
> to the spec

Let's not say that.  If it were true, we would break existing sites.  Yahoo mail 
is the prime example.

> If I set a cookie in IE4+ or Opera as ".thedomain.com", even without
> specifying the Domain or Path attributes, both IE4+ AND Opera read
> this cookie whether the user is at http://thedomain.com  OR
> http://www.thedomain.com

So you set a host cookie and which is invalid because of the leasding dot.  How 
a browser now interpret it is up for grabs.

What you have are two hosts which are named in a somewhat unorthodox manner.  
Instead of having site1.yourdomain.com and site2.yourdomain.com so that you 
could have two hosts in the same domain, you chose to name them such that one of 
the hosts looks like the domain that the other host is in.  And you are 
expecting to be able to pass cookies between them.  It's a bad senerio.

If you really want to do this, then you'll have to come up with work-arounds 
rather than rely on browser behavior when encountering invalid cookies.  And it 
looks like you have come up with a work-around, namely the redirect.

> Why should I have to do this workaround when the two other major browsers
> (if you can call Opera major) are flexible and work for all cases.  Why
> should Netscape be stingy and have to be worked around???

Because you have chosen to name your hosts in a manner which conflicts with 
domains.  That was your decision and you can't expect not to run into problems 
because of it.

I would be reluctant to change the cookie semantics in the netscape browser to 
accomodate this case even if, as you say, these are the semantics in the IE and 
Opera browser.  It's never clear if making such a change will break some other 
website who is doing something else that is unorthodox.

> I have a particular machine on a subdomain that I then give another
> name to specify the particular site on that subdomain:
>
> subdomain = newproject.dev.jake.com
>
> dev = a way to distinguish the machine this subdomain is being used
> on newproject = the site I am working on
>
> I ONLY want newproject to be able to read the cookies, so I want to
> set my cookie with the domain attribute being   
>
> ".newproject.dev.jake.com"

If you want to the cookie to be read only by the host "newproject.dev.jake.com", 
then you wouldn't set a domain cookie.  You would have that host set a host 
cookie (i.e., without specifying a "domain=" attribute) and that cookie will 
then be read by that host only.

OK, I just read further on in your comment and I see that you reached the same 
conclusion yourself.

> So, do I have a valid point here???  
>
> In short, IE4+ and Opera give me no problems, whereas Netscape gives me
> headaches whether or not Netscape is doing the "Right" thing and IE4+ and
> Opera are doing the "Wrong" thing.

I don't believe you have a valid point.  It's not whether netscape or microsoft 
or opera are doing the right or wrong thing in how the interpret the cookies.  
It's that you are doing the wrong thing in how you names your hosts.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → INVALID
Ok, I accept that my hosts are invalidly named.  Actually, I didn't' realize 
this before.  Lots of sites allow you to go to...say.....oh, I don't know 
http://netscape.com  for instance???  How about http://mozilla.org???

It is strange, but whether you go to netscape.com or www.netscape.com, they set 
cookies like this:  ".netscape.com"

So, can you tell me how they are expecting to read this cookie under 
http://netscape.com ?????  Of course Opera and IE4+ both can read this cookie 
under that URL.  It is Ironic that Netscape's own browser can't....Or can it?  
Is there a workaround that netscape is using to read these cookies under 
netscape.com that I don't know about???

I may be naming my hosts wrong, but I learned from the best (if you can call 
Netscape "the best" any more?).  So, given that lots of sites name their hosts 
incorrectly, is there any other solution to Netscape or Mozilla reading cookies 
than just tell me and lots of other sites that "you are naming your hosts 
incorrectly"?  I will certainly not make that mistake again, but others have 
made it and are living with something that, for various reasons, may not be 
easily changeable.

I think that given that IE4 (since 1997) and Opera (since its inception) have 
treated cookies in this way, you can't just say that they are all over the 
board on how they treat cookies.  They have been very consistent for at least 
the last 2 or 3 years.  Given that IE4+ owns most of the browser market share, 
I think it is important to support some of the basic things it supports.  
Otherwise, users will just say:

"Ah...Netscape (mozilla) just sucks!  I'm going to stick with my trusty old 
IE4+ even though I'd like to use Netscape.  It just doesn't work with the sites 
I use"

Now, I'm not saying you should support IE4+ proprietary DOM or anything like 
that, but being more flexible with cookies will end a lot of confusion when 
using Netscape (strict) -vs- IE4+ (relaxed).

I really want Mozilla to succeed.  That is why I am busting your butt on this 
so much.  If my point is not valid, I at least want to know that I made you 
look at the issue pretty hard.  I do think I have a point even if I am doing 
something that isn't to spec with domain names.

I didn't reopen the bug this time.  I'll let you decide that.

Jake



I admire your persistence.  And guess what?  You are correct.

I just went to http://netscape.com and then, using the cookie viewer, looked at 
what cookies got set.  I saw:

   host cookie:
     host=netscape.com, cookiename=c, value=1, expires=end-of-session

Then I went to http://home.netscape.com and here's what I got:

   host cookie:
      host=home.netscape.com, cookiename=c, value=1, expires=end-of-session
   domain cookie:
     domain=.netscape.com, cookiename=UIDS, cookievalue=<ip addr>

So if you go to http://netscape.com, the netscape browser is unable to set the 
domain cookie that netscenter is asking it to set.  That is very very bad!!!!

So I concede that we should change the cookie semantics in the netscape browser 
as follows:

- For the purposes of comain checking, host x.anything is to be considered as 
being in the domain .x.anything -- i.e., it should be able to set domain cookies 
for that domain and it should be sent any such domain cookies that are set.

Do you agree?

Thank you so much for forcing me to think about this.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: M15
Jud, this is a long-winded bug report but the conclusion is all summarized in my 
most recent comment above.  Do you agree with my conclusion -- i.e., our cookie 
semantics are wrong and even break our own netcenter site.  They should be 
changed as indicated.
>- For the purposes of comain checking, host x.anything is to be considered as 
>being in the domain .x.anything -- i.e., it should be able to set domain 
>cookies 
>for that domain and it should be sent any such domain cookies that are set.

>Do you agree?

yes, I believe I do.  Let me just restate what you said to make sure I 
understand you.

Let's say I have a site called:  jake.com

With the new way cookies will be validated, I could set a domain cookie such as:

.jake.com

This domain cookie would be setable and readable under the following URL's:

http://jake.com
http://www.jake.com

Would it also be the case that you could set a domain cookie for a site like:

.myproject.dev.jake.com

to be setable and readable under:

http://myproject.dev.jake.com

A host cookie would be more appropriate here, I know, but again, IE4+ and Opera 
read this just fine.

Am I on track with what you are proposing?

Jake
Yes to all the questions in your latest comment.
This would allow a host with less authority to set cookies for hosts with more
authority, when the opposite should be true; right?
Jud, please elaborate on your response.  I don't know what you mean by "more 
authority" and "less authority."

This issue is not one of authority but one of domain occupancy.  Is the host 
"netscape.com" a member of the domain ".netcape.com" or not?

-- Steve
steve and I just talked this over. we couldn't come up with any bustage. there
might be sites relying on the current behavior (though doubtful), but the change
does make sense.
*** Bug 31401 has been marked as a duplicate of this bug. ***
Fix checked in.  Changed file is nsCookie.cpp.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.