ayg wrote:

RFCs 2109 and 2965 both seem to give cookie expiration in terms of max age, not expiration date: http://tools.ietf.org/html/rfc2109 http://tools.ietf.org/html/rfc2965 If we're serving Expires instead of Max-Age on cookies, that implies we're using "old" cookies, so maybe we should just switch to "new" ones? Dunno how this would be accomplished or if it has any drawbacks.

(In reply to comment #1)

RFCs 2109 and 2965 both seem to give cookie expiration in terms of max age, not
expiration date: http://tools.ietf.org/html/rfc2109
http://tools.ietf.org/html/rfc2965 If we're serving Expires instead of Max-Age
on cookies, that implies we're using "old" cookies, so maybe we should just
switch to "new" ones? Dunno how this would be accomplished or if it has any
drawbacks.

We use setcookie(). setcookie() uses Expires, it seems.

+upstream?

ayg wrote:

Yeah, this is upstream, I guess. Is there any workaround we can use? Is there some reason to prefer Expires (e.g., reliability)?

I suppose we could construct our own cookies and send the headers... but reinventing the wheel sucks.

I'd much rather see us push this back upstream. The PHP docs say that they're following the older Netscape cookie spec (http://curl.haxx.se/rfc/cookie_spec.html). Provided that all the major browsers are supporting RFCs 2109 and 2965--and I would assume so, they're 13 and 10 years old, respectively--I would think PHP could get with the 21st century as well ;-)

ayg wrote:

Pushing it upstream would be fine by me, if anyone is willing to do it, and upstream is willing to accept it. This is hardly urgent enough that we need to work around it ourselves if we can tell users to just upgrade. But pushing upstream is harder than working around it ourselves.

I would just push it upstream and track it. As annoying as it can be, this does not seem worth another special case in mediawiki.

See http://bugs.php.net/bug.php?id=23955