RE: Issues with the cookie draft

On Fri, 21 Mar 1997, Dave Kristol wrote:
> What do others think?  The idea is, if the user agent or,
> presumably, the origin server, receives a Set-Cookie (Cookie) header that
> is non-conforming, the receiver *must* ignore the header.

Since cookies are widely set by content providers through simple server
extensions (as opposed to just by relatively few server implementors), I
think this is a bad idea.  All sorts of non-RFC readers will be setting
cookies.  Let's make it as easy on them as possible. I would want the
client to do its best to figure out the server's intent, while adhering to
the spec. 

I don't think our current predicament is really caused by clients being too
liberal in what they accept; it seems to have been caused by the lack of a
specification in the original cookie proposal for what a browser should do
with extra attributes in a set-cookie.  The RFC contains the line:

> 4.3.1  Interpreting Set-Cookie2 [...]
> The user agent should ignore attribute-values pairs whose attribute it
> does not recognize. 

...which should solve the problem we have been addressing.  I don't think
that just because we've had this problem, we should make the clients
require strict syntax.  What if two browsers have different interpretations
of a conforming cookie?  If they both reject non-conforming cookies and
disagree about what it means to conform, no one set-cookie syntax will
work, and we'll have to switch on User-agent -- please, let's not create
that problem again! 

>   > 4.3.2 Rejecting Cookies (how far into the domain do you go):
>   > I appreciate that it was a long and drawn out debate but that is not a
>   > sufficient rational for preventing perfectly reasonable behavior. The
>   > decision to stop at one domain level is completely arbitrary. It is no
>   > more and no less secure than 2 or infinite domain levels deep. I do not
>   > feel that an arbitrary choice is a good enough reason to include a
>   > requirement in a specification.
> 
> It wasn't completely arbitrary.  The goal was to protect privacy, and
> the rule in the spec makes it harder for cookies to "leak" to servers
> far removed from their origin.

I disagree that there was any arbitrariness involved on our part.  The
arbitrary factor is the designation of an organizational unit in a domain
name.  If you want to change this, come up with a rule that sufficiently
covers the following cases:

.com.	
.sun.com	
.foo.sg
.demon.co.uk	
.bar.com.au
.powells.pdx.or.us

On Fri, 21 Mar 1997, Roy T. Fielding wrote:
> I was hoping for "Set-Chips" (just a small addition to the cookie)
> or "Set-Brownie" (that other thing we find at IETF meetings).

Oi, what have you started.  ;)  How about "Set-Baking-Soda" -- that
required to make cookies fully baked? 

M. Hedlund <hedlund@best.com>

Received on Friday, 21 March 1997 20:12:09 UTC