Cookie2 规范的当前状态如何？
您是否有一些关于实现/计划实现 HTTP 1.1 规范这一部分的浏览器的信息？ 另外，哪些框架已经实现了此功能。 我已经完成了谷歌研究，但我想知道是否还有其他东西。
另外，你会/会使用它吗？ 您发现它比 Cookie/Set-Cookie 实现更好吗？
Do you have some information regarding browsers that implement/plan to implement this part of the HTTP 1.1 specification? Additionally, what frameworks have already implemented this feature. I've done my Google research but I'd like to know if there's something else.
Also, do/would you use it? Do you find it better than the Cookie/Set-Cookie implementation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更新：Cookie2 规范从未流行起来，RFC 6265 现在宣布它已过时，使这个问题变得毫无意义 - 尽管看到其失败原因的讨论可能仍然很有趣。
下面的答案是2009年写的，
我主要回答第二部分。
我最近对它做了一些研究，现在我坚定地认为不，它还没有准备好使用，我不会使用它。
找到适用于当前浏览器和代理的现有规范的具体数据很困难，因为 cookie 最初是一种专有的浏览器扩展，并且继续添加专有功能，例如最近的“仅 http”标志。 我认为总的来说，业界一直在继续使用这种准“Netscape 风格”与 RFC 2109 实现的混合，除了有关第三方 cookie 的更宽松的规则以及有时使用非引用字符串的一些奇怪行为。
至于我是否觉得它更好，通读规范确实显示了它的好处 - 即，客户端现在将路径、域和端口参数作为“美元”参数传回，因此 Web 应用程序知道要使用哪些参数删除/覆盖该 cookie。 使用 cookie 存储评论的能力将有一天对用户来说是一个胜利，因此他们有机会看到 cookie 用途的纯文本解释，但除非浏览器开始警告人们有关 cookie 的信息，否则谁会看到他们？
同时发送 set-cookie 和 set-cookie2 标头的需要也让我的纯粹主义者感到不安，就像客户端除了 Cookie 标头之外还需要发送 Cookie2 标头一样，当我查看它时，这似乎是不必要的。 YMMV。
Update: the Cookie2 specification never caught on, and RFC 6265 now declares it obsolete, making this question moot - though it's possibly still interesting to see a discussion of why it failed.
The answer below was written in 2009.
I'll mainly answer the second part.
I did some research into it recently and am now firmly of the opinion that no, it is not ready for use, and I would not use it.
Finding concrete data on the existing specification that will work with current browsers and proxies is difficult, because cookies started out as a proprietary browser extension and continue to have proprietary features added, like the most recent "http-only" flag. I think by and large the industry has continued to use this quasi "Netscape-style" mixed with RFC 2109 implementation, except with more loose rules about third-party cookies and some strange behaviour sometimes with non-quoted strings.
As for whether I find it better, a read through of the spec does certainly show its benefits - ie, the client now passes back the path, domain and port parameters as 'dollar' parameters, so a web app knows what parameters to use to delete/overwrite that cookie. The ability to store comments with the cookies will be a win for the user one day, so they get the chance to see a plain text explanation of what the cookie is for, but unless browsers start warning people about cookies, who is going to see them?
The need to send both a set-cookie and set-cookie2 header also upset the purist in me, as did the need for a client to send a Cookie2 header in addition to the Cookie header, which seemed unnecessary when I looked at it. YMMV.
阅读 RFC 6265，它废弃了 rfc 2965。它建议不要使用或实现 cookie2
Read RFC 6265 which obsoletes rfc 2965. It has advice not to use or implement cookie2
目前的状态是大多数浏览器仅完全支持初始 Netscape 的 Cookie 规范。
Set-Cookie/Cookie根据 RFC 2109 仅受某些浏览器（我不知道是哪一个）和Set-Cookie2/Cookie2支持，每个 RFC 2965 仅由 Opera 提供。The current state is that most browser only fully support the initial Cookie specification by Netscape.
Set-Cookie/Cookieper RFC 2109 are only supported by some browser (I don’t know which) andSet-Cookie2/Cookie2per RFC 2965 only by Opera.