Set-Cookie2: "additive" vs. "independent"

When I first wrote up a (not widely circulated) draft that introduced
Set-Cookie2, I made it an independent header.  That is, it was to be
treated independent of Set-Cookie, except that Set-Cookie2 for a given
cookie would supersede Set-Cookie for the same cookie.  I switched to the
"additive" solution that appears in the state-man-mec-xx I-Ds after concern
was raised that a server would have to send both Set-Cookie and Set-Cookie2
all the time, and, if the cookies were big, that would comprise a lot of
bytes.  The "additive" solution was to splice together cookies (actually,
attributes for cookies) from Set-Cookie2 onto corresponding cookies carried
in Set-Cookie, so the cookie name and value would only have to appear once,
which reduces the concern about the cookie's length.

Foteos Macrides and Dave Morris have expressed concern about the complexity
of the additive approach.  Indeed, from private conversation, I understand
that Foteos has some implementation experience that would support his point
of view.

Furthermore, both Foteos and Dave point out that a server would not need to
send Set-Cookie and Set-Cookie2 headers with each response.  A server could
send both headers the first time it instantiates a cookie and see what
flavor cookie comes back.  If it's an old-style cookie, the server makes
further responses using Set-Cookie.  If it's a new-style cookie, the server
makes further responses using Set-Cookie2.  Both cookies need not be sent.

In light of their observations, particularly Foteos's concerns about how
reliably the Set-Cookie and Set-Cookie2 headers can be aligned in
one-to-one correspondence, I think it would be safer to shift from the
current "additive" back to my original "independent" headers solution.  I
believe the problem of cookie size can be solved, as I described.

The one rub is how to handle gracefully a transition from old-style
("Netscape") cookies to new-style cookies.  The scenario I just described
above locks the dialog into either old- or new-style cookies, because the
server only sends one header, either Set-Cookie or Set-Cookie2.  What if
the user upgrades the UA to one that understands new-style cookies, but the
current cookie dialogs it engages in use old-style cookies?  We would like
the UA and server to begin exchanging new-style cookies.  But neither side
knows that the other understands new-style cookies.  Who goes first to make
their capabilities known?

I can think of two approaches, and I'm sure there are others.  One approach
is just to have the server periodically send both Set-Cookie and
Set-Cookie2 as a probe.  The cookie value might, for example contain the
timestamp of the last contact with the server, and the server could send
both headers once each day/week/whatever.

Simpler still, a UA that supports new-style cookies should be sending
	Cookie: $Version=0
followed by other cookie values.  If the server understands new-style
cookies, it could respond to further requests with Set-Cookie2.

I invite supporters of the "additive" approach out there who have remained
silent until now to speak up to defend it.  Otherwise I intend to switch to
the "independent" approach I describe here.

Dave Kristol

Received on Tuesday, 29 July 1997 06:39:46 UTC