This is an examination of three significant flaws in the recently published version of the HTTP State Management Mechanism (RFC6265) standard. There are other flaws, of course, but these are the first I came across.
This is a rant. This means that:
In practice, the problems are minor because, well, frankly, because virtually no-one ever followed the previous specifications to any great extent anyhow. For example, I have never once, in over a decade, seen a cookie with a Version attribute (mandatory since February 1997). Except when I use it, of course.
Nevertheless, I cannot see how obsoleting unused standards and replacing them with poor standards will help matters. The argument goes, that it will help to lay the groundwork for extending the standard later. But I am skeptical; RFC2109 was as close to the then-current state of things as RFC6265 is now. User-agent and server developers just did what they wanted; and that apparently did not mean following the specification (or, in the majority of cases, even reading it, it would seem).
Both Mozilla Firefox, and Google Chrome, have already changed their cookie-handling behavior, to treat quotes not as quotes but as literal characters, for - at least - the domain and path attributes. So RFC6265 has already created conflicts between what was previously supported from RFC2965 (and RFC2109), and what is now supported.
This does not apply to the cookie-value, which can be a quoted string. However, all browsers do still, and always have - strictly speaking, incorrectly - treated quotes in the cookie-value as literal characters. But, this was always desirable because, per the robustness principle, it kept both browsers and servers, that used the previous de facto standard, compatible with each other, and with both browsers and servers that used the new standard.
There was no need to compromise here. In the first case, because the browsers had, for many years, supported quoted-strings for attribute values. As the purpose of RFC6265 was to harmonize the standard with actual behavior, there was nothing to be gained by redefining this behavior. In the second case, because any server that followed the previous standard (RFC2109), would include the mandatory Version attribute, it would be obvious to a client as to whether the quotes should be literal characters or not. Prohibiting quoted-string values for these attributes does nothing except punish the few developers who followed the previous standard, and now find their code which has worked for over a decade, suddenly failing, with no explanation.
RFC6265 creates an orphan of other standards built upon the specifications it replaces - such as IETF BCP 44. It's not obsoleted, but it doesn't refer to a current specification, and the successor specification contradicts it.
For example, RFC2964:
Billions of cookies have been set by all sorts of servers with the explicit intent of transferring that information to another entity. All major browsers do, and always have, accepted most Cookies without explicit confirmation. The default method of secure stateful communication over HTTP is, and has for many years been, to log in through a web form and have an authentication token stored in a Cookie (HTTPS optional!).
This is not supposed to be a litany of complaints against server and browser vendors; rather, it points out how the apparent goal of RFC6265 to specif[y] the syntax and semantics of these headers as they are actually used on the Internet
is flawed. Not just because in this case it reduces the standard to the lowest (least functional, secure) denominator possible; but because, what difference does the mere technical format of the specification make, if it is consistently used outside the standard, and insecurely?
Given the goals involved, it would probably have been better, to have specified RFC6265 as Informational - rather than Standards Track - and describe the differences from the previous specifications. It would have given a digest of how vendors could reconcile the standard and actual practice, and how to attain compatibility until then. Instead, HTTP state management has become as big a mess within the IETF as it has become for everyone else, with the biggest losers being most users, and all developers who followed the standards.
The Max-Age value must be a number greater than zero. Despite this, specific instructions are given for how to handle values that are zero or less. This means that values of zero are in violation of the specification, despite the fact that values of zero are defined by the previous specifications (RFC2109 and RFC2965) to have a special purpose (to ensure that cookies are immediately discarded), and which is universally supported by those who supported the attribute at all. In fact, this is the behavior defined for the value of zero now, as well - and yet, you are not permitted to actually use a value of zero! There is therefore no exact method of ensuring that cookies are immediately discarded – all techniques will involve either: violating the specification; relying upon client-specific behavior; or accepting uncertain results.
Examples:
Old browsers that support the Netscape cookie specification, and browsers that support RFC6265, will delete the cookie foo, but browsers that support only the specifications in RFC2109 and RFC2965 will only delete the cookie at the end of the session.
Old browsers that support the Netscape cookie specification will delete the cookie foo, but browsers that support RFC2109, RFC2965, and/or RFC6265, will, after one second - but not immediately - delete the cookie. Successive requests, such as for images in a page, may include the Cookie header even though it is not intended to persist.
Browsers that support the Netscape cookie specification, and browsers that support RFC2109 and RFC2965, will delete the cookie foo; but, although it will work the same for new browsers that support RFC6265, the header does not conform to the specification of RFC6265.