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 11:58:31 UTC