- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Fri, 21 Mar 97 14:55:48 EST
- To: yarong@microsoft.com
- Cc: http-wg@cuckoo.hpl.hp.com
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