RE: Issues with the cookie draft
Dave Kristol (dmk@research.bell-labs.com)
Fri, 21 Mar 97 14:55:48 EST
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