Closed Bug 28956 Opened 26 years ago Closed 26 years ago

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

Categories

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

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jrspm, Assigned: morse)

References

(
URL
)

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: 26 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: 26 years ago → 26 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: 26 years ago → 26 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.