RE: Issues with the cookie draft

Version: Yes, the client would be required to send $Version = 1 in a
response, even though the server isn't required to send Version = 1 in
set-cookie2.

Security: Exactly, that is why I think the best thing to say is "When
the secure attribute is included the server expects that the cookie will
only be returned on a secure connection." We neatly side step the
various issues. If "secure" really needs to be defined then someone can
propose an extension to your spec to specify what type of security and
how to choose among multiple types.

Domain Depth: I await Koen's response.

When to return Domain: Ahh I see. Why is it that Domain doesn't allow
FQDN? This would still work w/the matching rules. I'm sure I am missing
something painfully obvious.

Domain and Path Ordering: Yes, indeed. Well as Larry likes to constantly
remind me in the DAV context, your name is first on the draft. =)

			Yaron

> -----Original Message-----
> From:	dmk@research.bell-labs.com [SMTP:dmk@research.bell-labs.com]
> Sent:	Friday, March 21, 1997 11:56 AM
> To:	Yaron Goland
> Cc:	http-wg@cuckoo.hpl.hp.com
> Subject:	RE: Issues with the cookie draft
> 
> Yaron Goland <yarong@microsoft.com> wrote:
>   > RE: $
>   > As the origin server sent out the cookie, why would the origin
> server
>   > also not know what sort of cookie it is receiving back? While it
> is true
>   > that the origin server may have sent out cookies with the name
>   > "Version", the origin server can then reliably detect that it is a
> new
>   > cookie by checking the second value and seeing that it is not a
> legal
>   > Netscape cookie value. It would seem that the "$" is not
> necessary.
> 
> The server doesn't know whether the user agent is V1-capable, so it
> has
> to be able to distinguish V0 from V1 cookies and their attributes.
> And
> it has to deal with the ',' vs ';' punctuation problem for multiple
> cookies.  (Netscape's original spec. separated cookies in Cookie by
> ';'.)
> We thought having a '$' to distinguish attributes made things much
> easier
> for the server.  It's not elegant, but it works.
>   > 
>   > Languages:
>   > As I mentioned in my original proposal, the accept-language header
> would
>   > server the purpose of choosing the language. In the worst case,
> the
>   > language is just English. The UTF8 Unicode encoding preserves the
> lower
>   > ASCII range so when dealing with downlevel clients, one sends UTF8
>   > English. I do admit woeful ignorance of the language tag issues.
> Any
>   > experts in the house?
> 
> I'm also really bad on the language issues.  That's why I asked for
> more
> details.  I get the gist of what you're asking for, but I don't
> understand
> the language and encoding issues clearly enough to know whether what
> you
> want is a good idea or how to write it into the spec.
>   > 
>   > Discard:
>   > I am fully aware of the Lab PC environment. That is why IE 4.0 NT
> will
>   > be shipping with both private and public personal caches. The
> private
>   > cache will only be available based on log-in. The public cache
> will be
>   > the default used by anyone who logs into the machine and who
> doesn't
>   > have a private cache. Thus the distinction your refer to is
> understood
>   > by the client. As such the client also has the ability to decide
> when to
>   > store a cookie and when not to. So changing the attribute to
> Private
>   > would mean "If you are using a user specific cache then you may
> keep
>   > this cookie across log-ins. If you are using a system wide cache,
> then
>   > the cookie must be purged on log-out." I believe this is closer to
> the
>   > desired functionality than the current Discard definition.
> 
> I would interpret the Discard language about "sessions" exactly as you
> have, namely that when a user logs out his/her cookies that are marked
> Discard get discarded.
> 
> I actually think it's unwise for a multi-user machine to store *any*
> cookies in some kind of shared cookie cache, but that's a separate
> discussion.
>   > 
>   > Including Version:
>   > I actually meant the comment to apply to Set-Cookie not Cookie.
> Given
>   > the use of the set-cookie2 header, version, when equal to 1, would
>   > appear unnecessary.
> 
> So is this what you mean?:  if the server sends a Set-Cookie2, then
> the
> user agent should assume Version=1 if the server does not send send
> Version= explicitly.  I suppose that's reasonable, provided the user
> agent sends $Version=1 in Cookie either way.
> 
>   > 
>   > Matching Security the cookie was transmitted with:
>   > I am not going to get religious on the issue, I am just concerned
> that
>   > the language requires impossible behavior. For example, if the
> system
>   > has used some out of band means to determine that it has an
> isolated
>   > connection to the server, for example, they are directly connected
> by a
>   > wire, it may be perfectly reasonable to send a secure cookie in
> clear
>   > text. I think the best option is to simply state that the server
> expects
>   > the cookie to be transmitted in a secure manner and leave it at
> that.
> 
> I made this change in response to a suggestion from Raymie Stata.  As
> I
> said once before, I can back it out.
> 
> As to your example, if the server can tell there's a direct connection
> to
> the client, it could send the cookie without "Secure".  But if the
> cookie
> is labeled "Secure", I think it's reasonable for the server to expect
> the
> client to use secure means to send it back.  I think we can agree that
> it's
> hard to say that in a concise and precise way.  Every way of being
> precise
> becomes a huge digression into security protocols, relative strengths
> of
> encryption, and lots of other stuff we don't want to get into here.
>   > 
>   > Dealing with Malformed cookies:
>   > My concern is that handling of end cases caused the state spec to
> have
>   > to be revved in the first place. I would think, given past
> experience
>   > with cookies, it would be best to dot every "i" and cross every
> "t". In
>   > this case I believe it to be appropriate to declare that malformed
>   > cookies must be ignored. This is especially the case given that
> HTTP
>   > provides no mechanism for the client to return error information
> to the
>   > server.
> 
> It's possible.  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.
> 
>   > 
>   > 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 realize you (Yaron) have an
> application where the two-domain offset isn't really "far".  Koen
> Holtman was the person most outspoken about the Domain= rules.
> Perhaps
> he would like to chime in?
> 
>   > 
>   > Quote David: "You cannot specify explicitly by Domain and Path the
>   > domain
>   > and path you get by default."
>   > If you are explicitly defining Domain and Path, what do you care
> about
>   > the default? Perhaps an example would help?
> 
> Okay.  Suppose I visit www.a.com.  If www.a.com sends me a cookie with
> no Domain=, then the default domain is "www.a.com" (no leading '.').
> I
> will only send that cookie back to www.a.com, not, for example,
> foo.a.com.  OTOH, if www.a.com sends me Domain=.a.com, (with a leading
> '.'), I will return the cookie to www.a.com, foo.a.com, etc.  Section
> 4.3.2 does not permit Domain=www.a.com.  Consequently, I can't force
> the first behavior with an explicit Domain=, only with its absence.
> Therefore the presence/absence of $Domain in Cookie has significance.
> 
>   > 
>   > Domain and Path Ordering:
>   > How about, cookies are first ordered by domain based on a byte by
> byte
>   > comparison. Within a domain, cookies are path ordered as
> specified.
> 
> For compatibility, the Path ordering ought to come first.  Then you
> could do Domain ordering.  Of course there are other details to
> specify:  Is that left-to-right, based on the Domain= attribute?
> Canonicalized to lower case?  What about the default (omitted) Domain=
> attribute?  What are the consequences of mis-ordered cookies, if any?
> 
> Dave Kristol

Received on Friday, 21 March 1997 15:46:20 UTC