First, I agree with others who say that RFCs are basically irrelevant for cookies. For Django we've discovered this in various ways e.g. issue 9824 - http://bugs.python.org/issue9824 - which has now been applied. We have also had to work around the stdlib behaviour here.

Second, I have implemented a patch for this, with tests, against trunk - please review.

After looking at the implementation, this seems like the best way to make Python conservative in what is produces and liberal in what it accepts, which seems to be what the thread converged on. BaseCookie will now silently discard cookie 'morsels' with a colon in their name (and all other irregularities) when loading from a string, rather than raise an exception.

This allows cookie parsing to continue, so that other cookies in the HTTP header will be found.

However, if in Python code you attempt to directly set a morsel with an illegal name, you will still get the error.

There is a more lax strategy: Simply add ':' to the _LegalChars variable.

This would allow morsels to be *read* that have a colon in their name. However, from the current implementation, it would be very hard to add that ability without also allowing the BaseCookie class to produce such cookies. This would also raise other issues about at what point an error should be raised for setting invalid cookies etc.

Also, allowing these illegal cookies to be read is a corner case that is much less important - it isn't needed either for Trac or for our needs in Django.

For these reasons, I decided against the more lax strategy.