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

All of these ideas have been considered and rejected because of the load
they place on the server. Turning a V1 cookie into a V0/V1 cookie, on
the server side, requires nothing more than inserting "CRLF
Set-Cookie2:" in the right place in the set-cookie header. The beauty of
the solution is that the server doesn't have to sniff UA headers, which
is expensive, or worry at all about who they are talking to. By just
inserting the string they guarantee that everyone will work properly
without the need for any conditional code.

	Yaron

> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Tuesday, March 25, 1997 12:19 PM
> To:	Dave Kristol
> Cc:	http working group
> Subject:	Re: Section 10.1.1 Combining Set-Cookie and Set-Cookie2
> 
> 
> 
> 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.
> 
> Dave Morris

Received on Tuesday, 25 March 1997 21:37:35 UTC