Closed Bug 227475 Opened 21 years ago Closed 21 years ago

add port the cookie was received from

Categories

(Core :: Networking: Cookies, enhancement)

x86
Windows 2000
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: hauser, Assigned: darin.moz)

References

Details

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
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Summary: add port the cookie was received from → add port the cookie was received from
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
> 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.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → WONTFIX
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. ***
You need to log in before you can comment on or make changes to this bug.