RE: Issues with the cookie draft

I'll come up with a rule to handle your cases as soon as you come up
with a rule to allow me to share cookies across:

companyname.com
productname.companyname.com
version1.productname.companyname.com
version2.productname.companyname.com
version3.productname.companyname.com

The current spec prevents sharing cookies amongst those servers. That
does not seem terribly reasonable.

		Yaron

> -----Original Message-----
> From:	M. Hedlund [SMTP:hedlund@best.com]
> Sent:	Friday, March 21, 1997 8:02 PM
> To:	Dave Kristol
> Cc:	Yaron Goland; http-wg@cuckoo.hpl.hp.com
> Subject:	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 Saturday, 22 March 1997 01:39:17 UTC