The bug is pretty clear by glancing at the sources, although perfectly OS-independent. In sessions.py lines 544-547:
string_cookie = os.environ.get(u"HTTP_COOKIE", u"")
self.cookie = Cookie.SimpleCookie()
self.output_cookie = Cookie.SimpleCookie()
self.cookie.load(string_cookie)
lines 544 makes it very likely that string_cookie
is unicode (though it might be a byte string from the environment, those u""
mean that the sessions.py
author is trying hard to get it as unicode!-). Meanwhile in Cookie.py lines 624-628:
if type(rawdata) == type(""):
self.__ParseString(rawdata)
else:
# self.update() wouldn't call our custom __setitem__
for k, v in rawdata.items():
line 624 only parses a byte string: anything else (including a unicode string!) is treated like a dict (whence the crash).
Obviously this Cookie.py is emphatically not the one this sessions.py was developed for. So what can possibly have happened...? Well, we do know of course that App Engine is strictly Python 2.5 and the Cookie.py we showed is that of Python 2.6. So let's look at Cookie.py in 2.5 (lines 618-621 in this version):
if type(rawdata) == type(""):
self.__ParseString(rawdata)
else:
self.update(rawdata)
so in 2.5, given an empty unicode string, the cookie (which subclasses dict) does self.update(u'')
... which is an innocuous no-op. The comment in 2.6 shows why the maintainer of Cookie.py switched to the current loop... which breaks when rawdata's u''
.
Long story short: install Python 2.5 on your Windows machine, and use that version with the GAE SDK, not the 2.6 you're currently using -- unless you truly love debugging of extremely subtle version differences where an incorrect use was innocuous in 2.5 but breaks in 2.6, like this one;-). Also enter a bug about this in the gaeutilities tracker, since that call to load
with an empty unicode string is simply wrong, even though in 2.5 it happens to be innocuous.
Specifically, get the appropriate Windows msi of 2.5.4 from here, depending on whether you have a 32-bit or 64-bit version of Windows.