Closed Bug 99311 Opened 23 years ago Closed 23 years ago

Cookies not remembered for different port numbers

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: hniksic, Assigned: morse)

Details

It seems that Mozilla 0.9.4 (the Sep 11 build) forgets cookies when I change the
port number.

I work on a development server which uses port numbers to distinguish different
servers on the same machine.  The server requires login and stores the
identification information in a cookie.  It appears that, when I log in into a
different server on the same machine, the cookie for the previous one is lost.

Use case: I log on to delirium:1280.  Everything works (including quitting the
browser and restarting -- the cookie is permanent.)  Then I go to delirium:9800.
 I get the login screen.  Good; the server is different.  Again, everything
works.  However, when I go back to delirium:1280, I get asked for login again. 
If I do log in, then when I go back to delirium:9800, I am asked for login
again.  And so on.

Please note that this worked well in 0.9.3.  I'm not sure how the bug was
introduced, but it makes Mozilla very hard to use on sites that use different
port numbers along with cookies.
Related to bug 99286? Changing component.
Component: Browser-General → Cookies
reassigning..
Assignee: asa → morse
QA Contact: doronr → tever
Could you please include a step-by-step procedure for reproducing this problem.  
Include the url's that you use.

What does IE and nav 4.x do in this case?
Dupe of bug #98034?
Andre: Bug #98034 apparently doesn't state whether the site in question uses
cookies.  If so, then it describes the same problem as this bug.

morse: a step-by-step procedure is pretty much in the original report, except
that the ``delirium'' server is a local development machine behind the firewall,
thus not accessible from the Internet.

It seems to be hard to find sites that use port numbers, which is probably why
this bug went undetected.  However, such sites do exist and it is very
disconcerting to have to log in on each access, especially when previous
versions handled it correctly.  If you cannot find testable sites, I'll try to
"open" two sites of mine so that you can access them for the purposes of testing.

Repeating should be pretty straightforward once you have the sites -- just log
to the site on one port and then to the one on the second port), then return to
the first site to check if the login is still remembered.  In my case, it
prompts me for login information (stored in a cookie) again.  If I type it in,
then the second site will prompt me when I access it.  And so on.

Regarding IE and Netscape 4.  IE has (or used to have) a similar bug, so I've
avoided using it for sites on different port numbers.  All versions of Netscape
I am aware of have handled this well, and so did Mozilla up to and including
Mozilla 0.9.3.

It's hard for me to comprehend how this ever could have worked differently.  In 
this case the same cookies are being shared by the site on the different ports, 
so it's understandable that the behavior is as you described.  This is perfectly 
correct behavior.

In any case, there's nothing that I can do about fixing this until you provide 
me with sites that demonstrate the problem (and that don't have the problem in 
Netscape 4.x).  Therefore marking this as wont-fix for now -- feel free to 
reopen when you can provide the sites to demonstrate the problem.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I believe I have narrowed down the behavioral change in Mozilla from 0.9.3 to
0.9.4 that caused the problem.  I also have a URL that demonstrates the change.
 Please bear with me.

Synopsis: when a page on a non-default port sets a cookie without specifying a
domain, Mozilla 0.9.3 and Netscape 4 stored the cookie as belonging to domain
HOST:PORT.  Apparently Mozilla 0.9.4 stores it under the domain HOST, without
storing the port number.

Both behaviors result in next access to the page returning the cookie.  However,
setting a cookie of the same name on a different port will override the old
cookie in Mozilla 0.9.4, whereas Mozilla 0.9.3 and Netscape 4 would store two
separate values.

A simple test case is available at http://muc.arsdigita.com:2005/cookies/set . 
The page simply sets a permanent cookie.  Here is how you can use it to witness
the change between Mozilla 0.9.3/Netscape 4 and Mozilla 0.9.4.

Netscape 4:
Start netscape and go to http://muc.arsdigita.com:2005/cookies/set .  A "done"
page should show up.  Close netscape and inspect the cookies.txt file.  An entry
that looks like this should be there:

muc.arsdigita.com:2005  FALSE   /cookies        FALSE   1293840000     
test_bogus      test_value

Mozilla 0.9.3:
Start mozilla and go to http://muc.arsdigita.com:2005/cookies/set .  A "done"
page should show up.  Go to "View Stored Cookies" and you will find a cookie
named "test_bogus" with value "test_value" stored under muc.arsdigita.com:2005.
 Remove the cookie to get it out of the way.

Mozilla 0.9.4:
Start mozilla and go to http://muc.arsdigita.com:2005/cookies/set .  A "done"
page should show up.  Go to "View Stored Cookies" and you will find a cookie
named "test_bogus" with value "test_value" stored under just muc.arsdigita.com,
without a specified port number.


I believe this change between Mozilla 0.9.3 and 0.9.4 caused the problems in
this bug and in bug 98034.  The fix I propose is to revert to how Mozilla 0.9.3
handled the test page above.  Please let me know if you need more information.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
I haven't tested this out, but I can believe that what the reporter is saying is 
correct because I just realized what changed.  So I'm confirming this bug.

The change occured with the patch for bug 84776.  That involved images instead 
of cookies, but it's the same problem and they use the same parsing logic.  In 
that case the complaint was that images coming from the same host but on a 
different port should be treated as the same image, whereas in this bug report 
you are saying that cookies from different ports should be treated as different 
cookies.  And the fact that reporter has an example where different port numbers 
to distinguish different servers on the same machine would give credence to the 
fact that they should be treated differently.

Sorry I didn't remember this sooner -- it would have saved the reporter all the 
trouble of setting up the test cases.  In any event, thank you for your 
persistence with this.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.5
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Oops, meant to close out as WONT_FIX rather than as RESOLVED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oops, ignore previous comment.  I'm getting confused as to which bug report I'm 
in.

This bug is indeed now fixed.  It has been fixed by backing out the patch for 
bug 84776.
Closing as fixed once again.  Sorry for all the noise.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
The symptoms of this bug have been reintroduced in 1.2beta,
in order to fix bug 142803.
In my opinion 1.2beta now has the correct behaviour. 


V/fixed.
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.