SillyDog701

[skodvavi]

I have two web server installs on the same host, listening to HTTP request on different ports. Both have the same app deployed on them. The app uses form based authentication to login. I startup the two servers, access the app on server1 from NS7.1, and it sets a JSESSIONID cookie, with hostname (without port number). Next, I access the app on server2, it overwrites the previous JSESSIONID because hostname in the URL is same, though port number is not. Now when I access the app on server1, the browser sends back the wrong JSESSIONID, and thus I have to login again. Next access to app on server2, I have to login again -and so on. Is there a solution to this problem. I dont see this problem in NS 7.0, because that browser stores both hostname and portnumber, when storing the cookie.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

[Fulvio]

I don't have 7.0, but 1.7.2 has a Send for line, which is in every case, for every type of connection in Mozilla1.7.2 (presumed cousin to the who know when will be born 7.2. I am not sure if this is the place, but I can understand the frustration, with dial-up (I have cable).

UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1; BCD2000; .NET CLR 1.1.4322)

[akbash]

skodvavi: The problem you describe has been reported to the Mozilla folks. (They develop the basic browser which AOL marketing occasionally modifies to make what they call "Netscape.") See for example bug 189784: cookies do not recognize port number and bug 227475: add port the cookie was received from. Fixing these bugs would require breaking bug 142803: Port is being stored as part of cookie domain.

Historically Mozilla/Netscape has flipflopped on whether cookies should be distinguished by port. Currently the browser does not, because of bug 142803. Sadly, the published cookie behaviour spec is open to some interpretation and even some points that are fairly clear are not followed precisely because websites exist which assume slightly off-spec behaviour implemented by slightly off-spec browsers. In my experience none of the browsers behave precisely the same at the fuzzy limits of the spec. The current feeling is that cookies should not be distinguished by port. This is nicely summarized in bug 142803 comment 28.

I believe that Mozilla discards all port information when storing cookies. Now, ha, my interpretation of the spec (RFC 2965) is that this is only mostly correct. And they say language was a useful invention. You can of course add comments to these bugs, hoping for a change. But please do so only if you know whereof you speak, and keep in mind that at least two bugs requesting a return of the older port-specific behaviour have been rejected.

Possible workaround: if these servers are located on a private LAN you could consider adding another DNS entry for the same host, to be used when accessing the other port number...

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040811 Firefox/0.9.1+

[skodvavi]

Thanks, abkash for the detailed reply. My application works quite well with IE - so IE cookie management must be port aware. Comments in bug 142083 that you pointed to, mention that IE cookie management is unaware of ports. I dont quite get it. Infact, IE cookies being port agnostic has been listed as one of the reasons why Mozilla cookies have been made that way.

UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)