Cookie 'expires' date is modified by locale

[Michael Lemaire]

When you set the locale to something other than english (I do this in my views.py)
the cookie sent by the server with the 'sessionid' has an expire date written with this locale,
which makes the cookie rejected by some browsers (like Safari for instance).

I do this at the top of my views.py (after django imports):
locale.setlocale(locale.LC_ALL,'fr_FR.utf8')

And the cookie sent in HTTP headers is:
Set-Cookie: sessionid=fdb004842a4142ac821ed522a78d54cd; expires=jeu, 08-nov-2007 12:30:48 GMT; Max-Age=1209600; Path=/

Most browsers seems to tolerate this, but not Safari.

[Karen Tracey <kmtracey@…>]

Restore old date formatting code

[Karen Tracey <kmtracey@…>]

This was previously reported and fixed in #4119, but then the formatting code was changed back to use strftime by changeset 6333 (to fix #2066). Attached patch restores the old code.

[Chris Beaven]

Good catch, Karen. This did cross my mind when I was updating my session middleware patch but I dismissed it.

My patch adds the following methods to django.utils.http (and refactors code which use them):

• cookie_date -- which formats the date to be compatible with the Netscape format

• http_date -- which formats the date to be compatible with HTTP

Note that the previous format we were using for a backwards compatible cookie date was actually incorrect, the spec says it should be DD-Mon-YY, not DD-Mon-YYYY.

[Chris Beaven]

Oh, it also replaces the reference to the rfc822 module (deprecated since 2.3) replacing with email.Utils

[Chris Beaven]

And sorry, thanks Michael for the report (creds for the initial patch though, Karen ;))

[Malcolm Tredinnick]

The problem with specs is that there are so many to choose from. RFC 2109 (not 2019 mentioned in the comments) was poorly accepted in practice and everybody implemented the original Netscape spec, which had four digit years to be compliant with, e.g., RFC 822. So our original code was correct in this respect. Cookies are the most inconsistently specified thing, even for browsers, which a history of poor specification. We only need one date formatting function here.

[Chris Beaven]

I'm guilty of combining patches again here. This ticket only needs cookie_date

...but while I was at it I thought I'd tidy up the HTTP date references too (the formatdate(...)[:26] + 'GMT' code everywhere seems a bit silly) so that's what http_date is for: HTTP headers. We could just use email.Utils.formatdate(usegmt=True) but that only came in in 2.4 so it seemed tidier to abstract it to our own util method.

Re the original Netscape spec - fair enough, I'll fix that.

[Gary Wilson]

Fixed in [6634].