sparklemotion/mechanize — pull request #295 by mmorearty (2013-02-20 00:46:37+00:00)
Title: Writing cookies: Prefix wildcard domains with "."

There was some discussion related to this issue in issue #293. Making this change will allow for better interop with other libraries that read cookie files (see below). What follows is a whole lot of justification for a very small change :)

If a cookie matches a wildcard domain, e.g. `(anything).example.com`, then the line written out to a Netscape-formatted cookies.txt file must begin with a dot, e.g. `.example.com` not `example.com`. This is redundant with the second field of the line, a `TRUE`/`FALSE` value indicating whether the domain is a wildcard, but that's the way it goes.

This is a little tricky, because there is no formal spec for the Netscape cookie file format. (There is, of course, a formal spec the format of the HTTP `Set-Cookie` header, but that's not the same thing as the cookie file.)

The unnecessary duplication (leading dot in the first field, plus TRUE/FALSE in the second field) seems to lead to all kinds of incompatibilities between different cookie libraries. For comparison:

* [curl/libcurl](https://github.com/bagder/curl/blob/master/lib/cookie.c#L512): When reading a cookie file, they allow, but ignore, the leading dot on the domain; they always respect the TRUE/FALSE flag in the second field. When writing a cookie file, if the second field is TRUE, they always put a leading "." on the domain.
* [Python](http://hg.python.org/cpython/file/tip/Lib/http/cookiejar.py#l2015): Requires that the presence or absence of the leading dot matches the TRUE/FALSE value in the second field; otherwise, rejects the whole cookie file.
* [Perl](http://cpansearch.perl.org/src/GAAS/HTTP-Cookies-6.01/lib/HTTP/Cookies/Netscape.pm): The second field (TRUE/FALSE) is ignored. The presence or absence of a leading dot on the first field is used to determine whether

The upshot of all this is that curl will be able to correctly read cookie files that were generated by the current Mechanize, but Python and Perl scripts will not.

All of the above libraries (curl, Python, and Perl), when _writing_ a cookie file, ensure that the presence or absence of a leading "." on the domain matches the TRUE/FALSE in the second field. Seems to me that Mechanize should do the same.

Mechanize's current behavior when _reading_ a cookie file is fine: It allows a leading dot, but that is overridden by the `TRUE`/`FALSE` of the second field. That matches curl's behavior.