loewis: In the Netscape cookie protocol (which is specified approximately, though ambiguously, and incorrectly in places, by cookie_spec.html), cookies sent from client to server in the Cookie: header do not include the path (neither as "path=/foo/bar", nor even as "$path=/foo/bar").  In valankar's first example of 2005-12-04 16:07, the two cookies must be interpreted as having different paths (if they do not have different paths, the client is not behaving correctly).  See the section titled "Second Example transaction sequence:" in cookie_spec.html for an example of this.  So, the part of cookie_spec.html you quote is not relevant (in fact, it refers to client behaviour, not server behaviour -- though it doesn't say so explicitly!).

BTW, I said earlier: "clients are supposed to (and do) send the most specific cookie last".  That's backwards: in fact, clients send the most specific (longest-path) cookie first.  Cookie.py always ignores all but the last cookie (it overwrites the first), so it will only store the least-specific cookie, so my point stands.

Also note that valankar's second example of 2005-12-04 16:07 is incorrect (unless he meant Set-Cookie: instead of Cookie:): the Cookie header should never contain path cookie-attributes (see penultimate paragraph of this comment, and perhaps more clearly, method cookielib.CookieJar._cookie_attrs()).  By "cookie-attribute" I mean a string of the form "<name>=<value>", i.e. the same thing as represented by instances of Cookie.Morsel .

AFAIK (not 100% sure here) when several cookies are returned, none of the cookie standards defines which cookie servers should or should not look at, so Cookie.py should probably make all of the cookies available through some interface.  If it chooses to only provide one cookie (as it does), it would seem that a good choice would be the first cookie in the string passed to .load(), since that should be the one with the longest path.  Cookie.py instead takes the last cookie (probably by accident).  That's not good, but I'm unsure whether it should be changed, since it may break old code.

I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and therefore a SimpleCookie instance) seems to represent multiple HTTP cookies.  Second, BaseCookie.load(string) treats attributes like "path" specially, and I do not understand why.  The documentation says you're intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if the client obeys any of the cookie protocols (either the de facto Netscape protocol or any of the RFCs) then HTTP_COOKIE should never contain a string like "; path=x", where x is replaced by any arbitrary string (assuming here that HTTP_COOKIE is always simply the value of the HTTP header named "Cookie", and for simplicity that there are no quoted strings in the Cookie header).  Third, BaseCookie does not allow storing several cookies of the same name.  As I understand it, this last problem is the one valankar was complaining about.

I've always found cookies highly confusing, I must say, so it's always possible I've got something mixed up by now... but I don't think so.