Re: Section 10.1.1 Combining Set-Cookie and Set-Cookie2

Foteos Macrides wrote:
> 
> "David W. Morris" <dwm@xpasc.com> wrote:
> >The combinatorial rules are difficult and must be implemented to some
> >degree by both the server and the client.  In addition, they are in
> >support of a transition interval. I think they should be dropped in the
> >interest of simplicity.
> 
>         Note also that though the section on combinatorial rules is
> the most complex in the draft, it does not apppear sufficient to ensure
> equivalent implementations across UAs and reliable exchanges between
> UAs and servers:
> 
>         The examples have alternating Set-Cookie and Set-Cookie2 headers
> when the Set-Cookie2 header is adding Version 1 attributes to an otherwise
> Version 0 cookie name=value and attributes, which would help simplify
> their combination, but no such ordering is stated as a requirement in
> the draft, and such alternation would not be necessary if no Version 1
> attributes other than Version are being use, i.e., if a Set-Cookie2 header
> is simply indicating that the server is Version 1 capable such that
> the UA should include the $Version, $Path and $Domain attributes in
> its Cookie headers.

Alternation is not "necessary".  I wrote the examples that way to emphasize
two points:
1) An existing application could easily upgrade to V1 cookies by outputting a
second header after the first.
2) Like headers might not appear consecutively.

Assuming a client aggregates like headers first, I think the hardest part of the
combining rules might be walking the combined Set-Cookie and Set-Cookie2 headers
in parallel and creating new Set-Cookie2 headers.

> 
>         If multiple cookies are included in Set-Cookie headers, and
> additional Version 1 attributes are provided via Set-Cookie2 headers
> but for some reason the numbers of cookies associated with the "old"
> and "new" headers do not appear equal, how much should be discarded
> (everything?)?  If the Set-Cookie2 header is simply indicating

That's a fair question.  I think the only *safe* thing to do is to discard all,
since there's no way to discern where an omission occurred.

> Verson 1 capability, should it then use a comma-separated list of
> Version="1" attributes to ensure matching for number of cookies, or

It could, or it could use separate Set-Cookie2 headers, each with a Version=1.

> use them as comma-serarated "fillers" if not all of the cookies in
> such a Set-Cookie header have other Version 1 attributes?  Note also

I guess the answer is yes (which makes the Set-Cookie2 effectively null).  But
why would an application want to send some V0 cookies and some V1?

> that in the Examples, the Set-Cookie headers have commas as separators
> for name/attribute sets, which is invalid for the "old" headers, and
> could be confusing to readers of the draft.

Please cite specific section/page/text.  My eyes may deceive me, but I only see
';' as attribute/value separators.

> 
>         Particularly since large headers are likely to be the result
> of cookie accumulations, and the UA is likely to have sent a Cookie
> header so that the server need not send both "old" and "new" headers
> in such cases, the concern for saving bandwidth during the transition
> period via a combinational strategy may indeed be penny wise but pound
> foolish with respect to reliability and consistency of implementations.
> 
>         Another possibility if for Version 1 capable UAs to indicate
> this in a request header, perhaps only when not sending a Cookie header
> with Version 1 attributes, which itself indicates this capability.

The down-sides of that approach are:
1) A UA would always send extra header information to indicate cookie
capabilities, even to servers that don't use cookies.
2) An application would have to look for such a header *or* for V1 cookies to
decide what kind of cookies to send.

Dave Kristol

Received on Wednesday, 26 March 1997 08:17:52 UTC