W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

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

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 25 Mar 1997 17:24:16 -0500 (EST)
To: dwm@xpasc.com
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2887
"David W. Morris" <dwm@xpasc.com> wrote:
>On Tue, 25 Mar 1997, Dave Kristol wrote:
>> David W. Morris wrote:
>> > 
>> > section in the whole document.  Why are we requiring UAs to combine
>> > the two headers?
>> > [...]
>> The complaint from some parties was that the NAME=VALUE part of cookies,
>> in particular, can be (and already is) quite large.  So sending it twice,
>> once in Set-Cookie and once in Set-Cookie2 would incur a lot of network
>> traffic.
>> I agree that sending a completely separate Set-Cookie2 header with its
>> own set of values would be much simpler.  But the network traffic that
>> results was deemed excessive.
>I think there are two alternative solutions to mitigate network traffic
>for that subset of cookie using application which need to update large
>pieces of data:
>  a.  Use out of band informantion such as the User Agent value to decide
>      which cookie to send
>  b.  Minimize the number of times a cookie is set. Perhaps multiple
>      cookies with only one needing upate.
>  c.  Restructure the application to maintain more state information
>      in the server.
>  d.  Once the first cookie is received by the server, it is only 
>      necessary to send one of the two formats.  I would speculate that
>      some percentage of large cookie values are related to shopping
>      basket usage and only get large in the course of multiple
>      interactions. 
>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.

	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
Verson 1 capability, should it then use a comma-separated list of
Version="1" attributes to ensure matching for number of cookies, or
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
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. 

	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.


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Tuesday, 25 March 1997 14:27:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC