There’s been various fundamental issues with “HTTP cookies” for ages, e.g. technically and policy-wise (i.e. privacy). The two extant formal specifications of cookies, IETF RFCs 2109 and 2965, as well as the original informal and incomplete “Netscape cookie spec”, have not been implemented uniformly across browsers and servers. Thus how cookies are actually constructed, parsed, and used in practice has been essentially technical folklore. Anyone wanting to craft a new browser or some other application or tool that needs to consume or send cookie headers had to reverse engineer how the browsers were actually doing it as there wasn’t (until now) an accurate specification an implementer could use for reference. This has led to divergence on edge-cases for cookies within various browsers, servers, and other tools.

We’ve been working with browser, server, and web app folk in an IETF working group, “httpstate“, to rectify this, and the draft spec was recently approved for publication as an IETF RFC at the “Proposed Standard” maturity level. This spec differs from the prior specs in that it specifies how cookies are actually used on the Internet today. Anyone crafting a new client or server can implement the spec and have an interoperable implementation as a result.

This is great in that getting this finally explicitly documented will be a key underlying piece of moving “the Web“, and the wider Internet its built upon, on towards its next stage(s). Hopefully, browsers and servers can now converge their “cookie behaviors” 🙂

Our more detailed blog post (which includes some history) is here..

‘HTTP State Management Mechanism’ to Proposed Standard
http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html

=JeffH sez check it out 🙂

Average Rating: 4.4 out of 5 based on 193 user reviews.

Leave a Reply

You must be logged in to post a comment.