Hello all,
On a pull request submitted via github, it was suggested to me that I
should write an RFC about the feature that I'm proposing as well as to
write about it here on the internals mail list.
However, creating new pages (including RFCs) on wiki.php.net doesn't
seem to be allowed for non-priviled users, so I'm forced to skip that
part.
The PR in question is located at the URL below, but note that I'm no C
coder and while I did test it, I'm in no way confident that it should
be implemented as is. The changes just seemed simple enough to do, so
I went with it. If not anything else, you should be able to understand
it more easily.
https://github.com/php/php-src/pull/238
What I'm proposing is that setcookie(), setrawcookie() and ext/session
should send the Max-Age attribute in the Set-Cookie header, as
described in RFC2109, RFC2965, RFC6265.
As shown in the subject, the absence of this attribute in
PHP-generated Set-Cookie headers is also listed as a bug:
https://bugs.php.net/bug.php?id=23955
Another one also related: https://bugs.php.net/bug.php?id=43439
In summary - it specifies the cookie lifetime in seconds, starting
from the current time. This means that it's a better solution than the
Expires attribute, as the user agent doesn't need to worry about
timezones and basically - it doesn't matter if its time settings are
correct.
It should also be noted that 0 (zero) or any negative value means that
the cookie should be immediately dropped.
Erroneous time settings is a problem for many users and for the
developers of web applications that they report this supposedly as a
bug and since I've personally faced such reports, I can tell - it's
really hard to debug and/or figure out the problem at first.
Considering this, I can imagine that this feature would solve a lot of
problems.
The listed RFCs specify that both Expires and Max-Age are optional
attributes, but due to the latter being relatively new - it might not
be supported by all browsers. Those that don't will ignore it, BUT
those that do - will give it a higher precedence.
To me, that makes it perfectly safe to send both Expires and Max-Age,
whenever the cookie lifetime has to be specified.
I've taken the chance to also switch the rest of the currently sent
attributes from all-lowercase to the so called StudlyCaps presentation
(e.g. expires -> Expires). Browsers should all match them in a
case-insensitive manner, but all of the RFCs list them as proposed. In
other words - this is irrelevant, why not do it for the sake of
consistency?
Btw, since the patch is against 'master', while compiling it appeared
that it's PHP 5.5 code in that branch. That's not intentional on my
part - if it was up to me, I'd include it in the very next release. :)
Cheers,
Andrey.
Hello all,
On a pull request submitted via github, it was suggested to me that I
should write an RFC about the feature that I'm proposing as well as to
write about it here on the internals mail list.
However, creating new pages (including RFCs) on wiki.php.net doesn't seem
to be allowed for non-priviled users, so I'm forced to skip that part.The PR in question is located at the URL below, but note that I'm no C
coder and while I did test it, I'm in no way confident that it should be
implemented as is. The changes just seemed simple enough to do, so I went
with it. If not anything else, you should be able to understand it more
easily.https://github.com/php/php-**src/pull/238https://github.com/php/php-src/pull/238
What I'm proposing is that
setcookie(),setrawcookie()and ext/session
should send the Max-Age attribute in the Set-Cookie header, as described in
RFC2109, RFC2965, RFC6265.As shown in the subject, the absence of this attribute in PHP-generated
Set-Cookie headers is also listed as a bug: https://bugs.php.net/bug.php?*
*id=23955 https://bugs.php.net/bug.php?id=23955Another one also related: https://bugs.php.net/bug.php?**id=43439https://bugs.php.net/bug.php?id=43439
In summary - it specifies the cookie lifetime in seconds, starting from
the current time. This means that it's a better solution than the Expires
attribute, as the user agent doesn't need to worry about timezones and
basically - it doesn't matter if its time settings are correct.It should also be noted that 0 (zero) or any negative value means that the
cookie should be immediately dropped.Erroneous time settings is a problem for many users and for the developers
of web applications that they report this supposedly as a bug and since
I've personally faced such reports, I can tell - it's really hard to debug
and/or figure out the problem at first. Considering this, I can imagine
that this feature would solve a lot of problems.The listed RFCs specify that both Expires and Max-Age are optional
attributes, but due to the latter being relatively new - it might not be
supported by all browsers. Those that don't will ignore it, BUT those that
do - will give it a higher precedence.
To me, that makes it perfectly safe to send both Expires and Max-Age,
whenever the cookie lifetime has to be specified.I've taken the chance to also switch the rest of the currently sent
attributes from all-lowercase to the so called StudlyCaps presentation
(e.g. expires -> Expires). Browsers should all match them in a
case-insensitive manner, but all of the RFCs list them as proposed. In
other words - this is irrelevant, why not do it for the sake of consistency?Btw, since the patch is against 'master', while compiling it appeared that
it's PHP 5.5 code in that branch. That's not intentional on my part - if it
was up to me, I'd include it in the very next release. :)Cheers,
Andrey.Thx Andrey for this,
As I noted in a bug comment https://bugs.php.net/bug.php?id=23955 , this
feature must be added to PHP for User Agent having a wrong local time to
compute cookie expiration in a safe way.
The fact that adding the header should just not change the behavior of UA's
not knowing it is a huge +1.
I dont like the idea of adding one more parameter to setcookie() and
friends to let the programmer control the generated headers (talked about
in the github issue comments)
Julien.Pauli
At last, I was able to write an RFC about this:
https://wiki.php.net/rfc/**cookie_max-agehttps://wiki.php.net/rfc/cookie_max-age
- Andrey
--
There's no mention in the RFC of how the functionality will work in PHP. Is
it possible to add example code of how it is to be used based on this
implementation? What BC breaks it introduced (if any)? Can there be an
option to use both Max-Age and Expires cookie attributes with the
introduced changes? How does the user know which attribute is being set?
None of this information seems to be in the RFC.
Quoting Sherif Ramadan theanomaly.is@gmail.com:
There's no mention in the RFC of how the functionality will work in PHP. Is
it possible to add example code of how it is to be used based on this
implementation?
"Max-Age" would simply be added to all Set-Cookie headers, after the
"Expires" attribute. I thought that was obvious, but I'll make sure to
add a few examples to make it clearer.
What BC breaks it introduced (if any)? Can there be an
option to use both Max-Age and Expires cookie attributes with the
introduced changes? How does the user know which attribute is being set?
None of this information seems to be in the RFC.
This is all (briefly) described under the "Technical details and
considerations" section - both attributes should be sent and no side
effects and/or breaking changes are expected.
As for how a user would know it - just like with the current cookies
being sent (either via setcookie() or by ext/session), by looking at
their Set-Cookie HTTP headers.
Quoting Sherif Ramadan theanomaly.is@gmail.com:
There's no mention in the RFC of how the functionality will work in PHP.
Is
it possible to add example code of how it is to be used based on this
implementation?"Max-Age" would simply be added to all Set-Cookie headers, after the
"Expires" attribute. I thought that was obvious, but I'll make sure to add
a few examples to make it clearer.
Well, even if it were obvious the RFC should be a technical specification
of what's being introduced. Things should be stated and explained there as
clearly as possible. At least so much so that people shouldn't have to
guess about what is going to actually happen when they run certain code.
For example, how are session cookies affected? What determines the actual
delta? I would assume it's the determined by the Unix timestamp supplied to
setcookie? Should setting this attribute in the response headers be
included automatically for session cookies? I would think it would, but I'm
not certain since it's not mentioned.
Other than some brief examples of usage and perhaps including those small
details I think it's pretty clear and I like the idea :)
Thanks for taking the time on that.
What BC breaks it introduced (if any)? Can there be an
option to use both Max-Age and Expires cookie attributes with the
introduced changes? How does the user know which attribute is being set?
None of this information seems to be in the RFC.This is all (briefly) described under the "Technical details and
considerations" section - both attributes should be sent and no side
effects and/or breaking changes are expected.As for how a user would know it - just like with the current cookies being
sent (either viasetcookie()or by ext/session), by looking at their
Set-Cookie HTTP headers.
Yes, of course - those are all valid points that you've listed.
Updated the RFC with the suggested additions. Hopefully it's more
easily understandable now. :)
Quoting Sherif Ramadan theanomaly.is@gmail.com:
Well, even if it were obvious the RFC should be a technical specification
of what's being introduced. Things should be stated and explained there as
clearly as possible. At least so much so that people shouldn't have to
guess about what is going to actually happen when they run certain code.For example, how are session cookies affected? What determines the actual
delta? I would assume it's the determined by the Unix timestamp supplied to
setcookie? Should setting this attribute in the response headers be
included automatically for session cookies? I would think it would, but I'm
not certain since it's not mentioned.Other than some brief examples of usage and perhaps including those small
details I think it's pretty clear and I like the idea :)Thanks for taking the time on that.
Hi!
"Max-Age" would simply be added to all Set-Cookie headers, after the
"Expires" attribute. I thought that was obvious, but I'll make sure to
add a few examples to make it clearer.
I think it makes sense, only note is that it makes no sense to set
Max-Age to any negative number, especially as RFC 6265 treats all
negative values and 0 as the same:
If delta-seconds is less than or equal to zero (0), let expiry-time be
the earliest representable date and time. Otherwise, let the
expiry-time be the current date and time plus delta-seconds seconds.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
It is briefly noted in the RFC (mine, not 6265) that negative values
and 0 have the same effect. It's practically irrelevant which one is
sent.
My original commit actually did checks for negative values and sent
zeros instead of them, but then somebody on github pointed out that
they are legal, so I removed that logic. If not anything else, it
saves a few lines of code.
- Andrey
Quoting Stas Malyshev smalyshev@sugarcrm.com:
Hi!
"Max-Age" would simply be added to all Set-Cookie headers, after the
"Expires" attribute. I thought that was obvious, but I'll make sure to
add a few examples to make it clearer.I think it makes sense, only note is that it makes no sense to set
Max-Age to any negative number, especially as RFC 6265 treats all
negative values and 0 as the same:If delta-seconds is less than or equal to zero (0), let expiry-time be
the earliest representable date and time. Otherwise, let the
expiry-time be the current date and time plus delta-seconds seconds.