User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031129 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031129 Sure, this may not be part of the RFCs specifying cookies, but e.g. if you use multiple tomcat instances on different ports, it may well be interesting to be able to see from which one your JSESSIONID came from Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: . Expected Results: . see also Bug 144822
we've already decided cookies are port-agnostic. exercise for the reader: find the bug on that issue :) wontfix
excercise for the wontfixer: this was never a bug, but an RFE = "request for enhancement". To my understanding this bugzilla also takes RFEs - if not, please remove the option from the menus. Who is "we" who makes such decisions about being "port-agnostic"? Are those decisions published anywhere? Can they be appealed? Anyway, as said before: I don't expect Mozilla to do anything beyond recording for the completeness of the audit trail from which port a cookie came from.
> To my understanding this bugzilla also takes RFEs - if not, please remove the > option from the menus. Yes, you can file rfes in bugzilla. But that doesn't mean the requests can't be denied. (for example, if they violate the spec) > Who is "we" who makes such decisions about being "port-agnostic"? Are those > decisions published anywhere? Can they be appealed? usually, the module owner and/or peers take those decisions. Like here. > Anyway, as said before: I don't expect Mozilla to do anything beyond recording > for the completeness of the audit trail from which port a cookie came from. We don't store an audit trail at all. We don't even store the original path that set the cookie. Or the actual site being visited. Why bother about the port?
Michiel, Now I am confused, at least my cookie manager does show paths? Re: "why bother about the port": While developing you may have different versions of a webapp run on different ports, but on the same machine. Thus - with knowing from which port the cookie came from, you know from which webapp instance it came. "Audit Trail" is probably a too big word for the ~5 Bytes per cookie of extra storage I am asking for. And sure, I am fine if this port is only visible in "advanced" mode not to confuse normal users. Thx r.
if http://foo.com/pages/bar.php sets a cookie with path=/, we only store /. That is what you see in the cookie manager. The information that /pages/bar.php originally set the cookie is not stored. I think storing the port is too much overhead for too little gain. There are other workarounds for your problem, like different virtual hostnames or different paths. Why store information that 99.999% of the users will never use?
mvl's explained it perfectly already, so i'll just add this - if you want port information for "audit trails", consider using cookie logging. instructions for windows can be found at http://bugzilla.mozilla.org/show_bug.cgi?id=193951#c1, same idea on linux. this sounds just fine for your purposes, and will log the complete URI spec (including port) of the host that set the cookie. i'm going to wontfix this again, this time with the more explicit reason that it doesn't make sense to implement this feature for the reasons mvl listed.
This is almost a dup of bug 189784, "cookies do not recognize port number".
*** Bug 271467 has been marked as a duplicate of this bug. ***