Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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.