它是可选的。

可以指定端口，因此cookie可以是特定于端口的。这是不必要的，web服务器/应用程序必须关心这个。

来源:德文维基百科文章，RFC2109，第4.3.1章

它是可选的。

可以指定端口，因此cookie可以是特定于端口的。这是不必要的，web服务器/应用程序必须关心这个。

来源:德文维基百科文章，RFC2109，第4.3.1章

这是cookie SOP(同源策略)中的一个很大的灰色区域。

理论上，可以在域中指定端口号，cookie不会被共享。实际上，这在几种浏览器中都不起作用，您还会遇到其他问题。因此，只有当你的网站不是面向大众的，并且你可以控制使用什么浏览器时，这才可行。

更好的方法是为相同的IP获取2个域名，并且不依赖端口号进行cookie。

我在同一台机器上运行(并尝试调试)两个不同的Django应用程序时遇到了类似的问题。

我用这些命令运行它们:

./manage.py runserver 8000
./manage.py runserver 8001

当我登录了第一个，然后在第二个，我总是注销了第一个，反之亦然。

我在我的/etc/hosts上添加了这个

127.0.0.1    app1
127.0.0.1    app2

然后我用这些命令启动了这两个应用程序:

./manage.py runserver app1:8000
./manage.py runserver app2:8001

问题解决了:)

在IE 8中，cookie(仅针对本地主机进行验证)在端口之间共享。在FF 10中，它们不是。

我公布了这个答案，以便读者至少有一个具体的选项来测试每个场景。

根据RFC2965 3.3.1(浏览器可能遵循也可能不遵循)，除非通过Set-Cookie报头的port参数显式指定端口，否则cookie可能会或可能不会被发送到任何端口。

谷歌的浏览器安全手册说:默认情况下，cookie范围仅限于当前主机名上的所有url，而不绑定端口或协议信息。没有办法将cookie限制为单个DNS名称[…]同样，也没有办法将它们限制在特定的端口上。(另外，请记住，IE根本不会将端口号考虑到其同源策略中。)

因此，在这里依赖任何定义良好的行为似乎都不安全。