Hi, Jeff Hodges and Bil Corry here:
The IESG recently approved the Internet-Draft 'HTTP State Management Mechanism' (draft-ietf-httpstate-cookie-23.txt) for publication as a Proposed Standard RFC...
<http://www.ietf.org/mail-archive/web/http-state/current/msg01257.html>
This is great news in that the prior two IETF RFCs specifying "cookies", as well as the original informal and incomplete "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 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.
The new specification, draft-ietf-httpstate-cookie, 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. [note that an RFC number is not yet assigned, it ought to be done in several weeks, and the proper RFC published in a couple months]
A Bit of History..
Before getting to the present-day spec, a bit of history will provide appropriate context:
The original Netscape "cookie spec" was written by Lou Montulli sometime in the mid-nineties. By late 1995, three proposals for adding "state management" to HTTP were circulating in the technical community. A subgroup of the IETF HTTP working group formed to address this "state management" question, and eventually produced RFC2109, which attempted to be backwards compatible with the "netscape cookies" while offering some enhancements. After three more years, they produced RFC2965, which offered yet more enhancements and was distinct from the "netscape cookies". There are many fascinating details this terribly brief summary overlooks, not the least of which is that the cookie effort participants found themselves unexpectedly situated at the intersection of technology and public policy when privacy concerns began to be raised. Dave Kristol, who was co-author with Montulli on RFCs 2109 and 2965, wrote a detailed account of the entire process, which curious parties are encouraged to read..
Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
Now, fast forward to late 2008, when Bil Corry, a web app security specialist who participates in the OWASP and other web app security fora, connected with Jim Manico, another figure in that cohort, to try to foster some cohesiveness with respect to the fragmented approach to a relatively commonly implemented, but unspecified cookie "flag" named "HttpOnly". Bil and Jim saw the security issues arising from how the browser vendors were implementing HttpOnly in varying ways due to a lack of a specification and formed an ad-hoc working group to tackle the issue.
When Bil approached the IETF about forming a charter for an official working group. He was told that he was <quote> "wasting [his] time" because cookies themselves did not have a "proper specification" -- i.e. one that accurately reflected their use on the Internet today -- so it didn't make sense to work on a spec for the HttpOnly cookie flag. Soon after, they pursued reopening the IETF httpstate Working Group to tackle the entire cookie spec issue, not just the HttpOnly flag. Eventually Adam Barth would become the specification editor and Jeff Hodges the (reconstituted) IETF httpstate working group chair.
Now, Some Thanks..
We thank the participants of the original ietf-httponly-wg effort, especially Jim Manico, for helping to kick-start this effort.
Thanks to Adam Barth, the specification editor, and also the keeper, and implementor of, the test cases and test harness, for hanging in there with an unfamiliar IETF process and crowd, taking the time to travel to some IETF meetings, and plugging away until we have a finished spec.
Thanks to our area director, Peter Saint-Andre, whose expert navigation of the IETF document and IESG processes was also an instrumental contribution.
We also thank the broad array of participants in the IETF httpstate working group, both online and in person at our sessions at IETF meetings -- your contributions were critical to crafting a high-quality spec and navigating the approval process. Here's the acknowledgements section from draft-ietf-httpstate-cookie where all these folks are noted..
This document borrows heavily from RFC 2109 [RFC2109]. We are
indebted to David M. Kristol and Lou Montulli for their efforts to
specify cookies. David M. Kristol, in particular, provided
invaluable advice on navigating the IETF process. We would also like
to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
valuable feedback on this document.
In Summary..
This spec is a milestone in that HTTP "cookie" syntax and behavior has been
effectively a matter of undocumented folklore all these years. 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).
Note also that although the HttpOnly flag is now nominally documented in draft-ietf-httpstate-cookie, there remains undocumented behavior, for example, interactions with XMLHttpRequest. So now with a firm foundation, Bil (or others) can address these HttpOnly spec deficiencies.
Comments