Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64223
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bofh.bg from 212.50.12.79 cause and error)
Message-ID: <20121210142818.9erzxulg08cwwck8@mail.orbitel.bg>
Date: Mon, 10 Dec 2012 14:28:18 +0200
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.6)
Subject: Bug #23955: Cookie Max-Age attribute
From: narf@bofh.bg (Andrey Andreev)

Hello all,
On a pull request submitted via github, it was suggested to me that I =20
should write an RFC about the feature that I'm proposing as well as to =20
write about it here on the internals mail list.
However, creating new pages (including RFCs) on wiki.php.net doesn't =20
seem to be allowed for non-priviled users, so I'm forced to skip that =20
part.

The PR in question is located at the URL below, but note that I'm no C =20
coder and while I did test it, I'm in no way confident that it should =20
be implemented as is. The changes just seemed simple enough to do, so =20
I went with it. If not anything else, you should be able to understand =20
it more easily.

https://github.com/php/php-src/pull/238

What I'm proposing is that setcookie(), setrawcookie() and ext/session =20
should send the Max-Age attribute in the Set-Cookie header, as =20
described in RFC2109, RFC2965, RFC6265.

As shown in the subject, the absence of this attribute in =20
PHP-generated Set-Cookie headers is also listed as a bug: =20
https://bugs.php.net/bug.php?id=3D23955

Another one also related: https://bugs.php.net/bug.php?id=3D43439

In summary - it specifies the cookie lifetime in seconds, starting =20
from the current time. This means that it's a better solution than the =20
Expires attribute, as the user agent doesn't need to worry about =20
timezones and basically - it doesn't matter if its time settings are =20
correct.

It should also be noted that 0 (zero) or any negative value means that =20
the cookie should be immediately dropped.

Erroneous time settings is a problem for many users and for the =20
developers of web applications that they report this supposedly as a =20
bug and since I've personally faced such reports, I can tell - it's =20
really hard to debug and/or figure out the problem at first. =20
Considering this, I can imagine that this feature would solve a lot of =20
problems.

The listed RFCs specify that both Expires and Max-Age are optional =20
attributes, but due to the latter being relatively new - it might not =20
be supported by all browsers. Those that don't will ignore it, BUT =20
those that do - will give it a higher precedence.
To me, that makes it perfectly safe to send both Expires and Max-Age, =20
whenever the cookie lifetime has to be specified.

I've taken the chance to also switch the rest of the currently sent =20
attributes from all-lowercase to the so called StudlyCaps presentation =20
(e.g. expires -> Expires). Browsers should all match them in a =20
case-insensitive manner, but all of the RFCs list them as proposed. In =20
other words - this is irrelevant, why not do it for the sake of =20
consistency?

Btw, since the patch is against 'master', while compiling it appeared =20
that it's PHP 5.5 code in that branch. That's not intentional on my =20
part - if it was up to me, I'd include it in the very next release. :)

Cheers,
Andrey.